
Computer Communications Trends 
LisaLeaming 

Spacecraft Data-Processing Hardware 
Can SD1 Software Be Error-Free? 
Taulbee Report 















RoaHor Sprvipp Ni 












SIMULATION NEWS 


Announcing new 

PC SIMSCRIPT II.5 with SIMANIMATION 

your results are easy to understand 
your recommendations are more likely to be acted upon 


Before 


After 



W ith PC SIMSCRIPT II.5 
and the new simulation 
animation, your results are easy to 
understand - - moving pictures, 
histograms, pie charts and plots. 

Because your results are under¬ 
stood, your recommendations are 
more likely to be acted upon. 

You can save your organization 
lots of money and further your 
career. 

Simulation simplified 

SIMSCRIPT II.5 gives you a 
compact English-like language. 

Your simulation program reads like 
a description of the system you are 
studying. 

Your model development, check¬ 
out, modification and enhancement 
are greatly simplified. 

Fully supported 

SIMSCRIPT II.5® is a well 
established, standardized, and wide¬ 
ly used language with proven soft¬ 
ware support. 

Typical applications include: 
military planning, manufacturing, 
communications, logistics, and 
transportation. 



With PC SIMSCRIPT II.5® you 
get results sooner and they are bet¬ 
ter understood. 


Free trial and training 

The free trial contains every¬ 
thing you need to try PC SIM¬ 
SCRIPT II.5 on your computer. 

We send you PC SIMSCRIPT 
II.5, installation instructions, sam¬ 
ple models, and a complete set of 
documentation. 

You can build your model or 
modify one of ours. If you have 
questions, just call us. No cost or 
obligation. 

For a limited time we also in¬ 
clude free training. 

Act now to avoid disappoint¬ 
ment. 

For immediate information 

Call Rick Crawford at (619) 
457-9681. In the U.K., call Steve 
Wombell at (01) 940-3606. 


Act now for free training 

Free trial-learn the reasons for the 
broad and growing popularity of PC SIM¬ 
SCRIPT II.5 —no cost or obligation. 

Special offer-return the coupon today 
and we will include one free course enroll¬ 
ment worth $950. 


Organization 





Return to: 

CACI 

3344 North Torrey Pines Court 
La Jolla, California 92037 

Or, better yet, call Rick Crawford at 
(619) 457-9681 
In the U.K. 

CACI 

26 The Quadrant 

Richmond, Surrey, England TW9 1DL 

Call Steve Wombell at (01) 940-3606 


SIMSCRIPT II.S, SIMANIMATION, and PC 
SIMSCRIPT II.5 are registered trademarks and service 


marks of CACI, INC.-FEDERAL 
©1986 CACI, INC.-FEDERAL 
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1987 Winter USENIX 
Technical Conference 
Omni Shoreham— 
Washington, D.C. 
January 21-23,1987 


TECHNICAL SESSIONS 

Wednesdayjanuary 21— 

WHAT IT IS TO BE UNIX:* 

A few simple notions and where they lead. 
Seven invited talks by leading experts will examine 
and evaluate the key aspects of UNIX, its evolu¬ 
tion, its past and present roles, its various commu¬ 
nities, and its successes and failures in meeting 
their needs and objectives. 
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UNIX PERFORMANCE 

The day will focus on performance and UNIX 
systems, including case studies, performance pre¬ 
diction methodologies, techniques for improving 
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UNIX-BASED DATA MANAGEMENT SYSTEMS 
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databases, as well as the problems associated with 
data integrity will be explored. 



TUTORIALS ON UNIX TOPICS 

Presented by leading UNIX experts, the tutorials 
provide in-depth coverage of essential issues in 
UNIX technology. The schedule includes: 4.3BSD 
and System V Internals; Networking Courses on 
NFS, RFS, and Managing a LAN; Designing Device 
Drivers; Software Development Using C & UNIX; 
Adv. Programming in C; Graphics; AI and the UNIX 
Environment; Performance Measurement/Analysis; 
Implementing Windowing Systems on Berkeley 
UNIX; and, Advanced System Administration 
(System V). 

THE SPONSOR 

The USENIX Association is a non-profit association 
of individuals and institutions interested in foster¬ 
ing innovation and sharing ideas, software, and 
experience where UNIX and UNIX-like systems 
and the C Programming Language are concerned. 
USENIX sponsors technical conferences and work¬ 
shops and an annual vendor exhibition; publishes 
;login:, a bimonthly newsletter; and serves as 
coordinator of a software exchange for appropri¬ 
ately licensed members. The individuals and insti¬ 
tutional members of USENIX are interested in 
problem solving with a practical bias, with 
research that w'orks, and with timely responsive¬ 
ness within a community made up of executives 
and managers, programmers and academics. 


The Professional and 
Technical UNIX Association 


For complete conference information, call: (213) 592-1381 or (213) 592-3243 
Or write: USENIX Conference Office, P.O. Box 385, Sunset Beach, CA 90742 
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‘UNIX is a registered trademark of AT&T 




FROM THE EDITOR-IN-CHIEF 


To our readers 

As we near the end of the year, it 
seems timely to share with you some 
behind-the-scenes efforts to maintain the 
high quality of Computer. 

These have been tough times. For the 
past year and a half, due to the industry 
recession, we have seen a slowing of 
Computer Society revenues and 
membership growth. This has had an 
impact on Computer, the society’s 
flagship publication. Computer’s editor- 
in-chief and staff have worked diligently 
to implement 1986 page-budget cuts 
directed by the Board of Governors. 
These cuts have reduced the magazine by 
at least two technical articles and five or 
more departmental pages per issue. 
Unfortunately, as many of you have 
noticed, these page limitations—plus 
press-imposition economies—have 
occasionally precluded publication of 
entire magazine departments. There was, 
for example no “Calendar” section or 
“Book Reviews” department in the 
September issue. 

On the plus side, I wish you could 
have seen how hard our editors, authors, 
and, most of all, our Computer 


managing editor and staff worked to 
implement the page cuts while main¬ 
taining quality—the highest of any 
technical publication in our profession. 
There were times when I felt it could not 
be done. But it was done, and our fine 
Computer Society authors and perma¬ 
nent staff made it possible. We do, of 
course, hope that these page reductions 
will be temporary and that pages will 
increase in 1987 as the industry and the 
Computer Society return to a more 
healthy state. 

You may be interested in hearing that 
Computer, by all measures (that is, 
readership surveys, letters to the editor, 
telephone calls, membership comments, 
and reference citations by other maga¬ 
zines and journals), is clearly tops among 
peer-reviewed publications in the world. 
We should all be proud of this contin¬ 
uing recognition. The editor-in-chief and 
the Editorial Board are particularly 
proud of the positioning of the technical 
articles; we have about 50 percent 
industry-authored and 50 percent 
academic-authored pages. We have tried 
very hard to encourage joint indus¬ 
try/academic-authored articles, and we 



have been successful. The result is a 
balance that, we hope, supports our 
society’s working professionals in both 
industry and academia. 

Another important acknowledgment 
that I would like to share with you is 
recognition of five Editorial Board 
members who have completed their 
terms: Peter Chen, Amrit Goel, 
Demetrios Michalopoulos, Leon 
Osterweil, and Ed Parrish. As board 
members, they have contributed to the 
success of Computer. 

Thanks also to you, our readers, for 
your support of the Computer Society 
and its flagship publication. Keep the 
high-quality articles and special-issue 
proposals flowing; Computer's quality 
depends directly on the publication of 
your technical work. 

Michael C. Mulder 

Editor-in-Chief 



A Headquarters In Jackson: 

Y our key to 

PROFITABLE 

RETURNS. 


Whether you are designing software, manu¬ 
facturing hardware or simply selling your 
wares, you'll find Jackson is a city that is online 
to a great future. At least that's the opinion 
of The Fantus Company, the nation’s most 
respected site selection specialists. They were 
turned on by Jackson’s abundant labor supply, 
available plant and office space, efficient 
distribution channels and quality of life. We 
encourage you to ask for more input. Call 
or write: 

Jackson Chamber of Commerce 

P.O. Box 22548 

Jackson, MS 39225-2548 _ 

(601)948-7575 

Jackson 

~ M/ The Bold New City 


Reader Service Number 3 













LETTERS 


The “collision”: 

Our fault or “no fault”? 

To the editor: 

Right off the bat, let me make it clear 
that I sympathize with the plight of 
computer science departments to “pro¬ 
duce” (the authors’ term) enough grad¬ 
uates and doctors for the rising demand 
(“Imbalance Between Growth and 
Funding in Academic Computer Science: 
Two Trends Colliding,” September 
Computer, pp. 70-74). However, the 
thought apparently never crossed the 
authors’ minds that the “product” may 
be defective. 

In the age of Gramm-Rudmann, any 
support for CS education will have to 
come from the industry that needs the 
graduates. If the decision makers in that 
industry regard the CS curriculum as in¬ 
adequate, or even irrelevant, they will 
not open their purse strings. As an 
editor and technical writer for a large 
trade magazine, I have been talking to 
many of these managers over the last 10 
years. Some, in fact, regard a CS educa¬ 
tion as detrimental to their needs. 

Only partly can such an attitude be 
explained by the fact that few of today’s 
decision makers had any formal CS edu¬ 
cation themselves. More to the point is 
the perception that there really is no 
such thing as computer science, that 
students are consequently burdened with 
esoteric mathematical concepts, and that 
they learn nothing about the principles 
of design. (Because mathematicians 
don’t construct things, while engineers 
do, CS departments with EE roots obvi¬ 
ously suffer less from this last deficiency.) 

CS faculties, and indeed the leader¬ 
ship of our Computer Society, should 
search their souls for solutions to the 
dilemma—whether perceived or real. 

One observation should give us infor¬ 
matics folk pause, though: Industry ap¬ 
pears anxious to soak up BSEE novices. 
Most ads for software people, on the 
other hand, stipulate “experience re¬ 
quired.” Even some of our most reputa¬ 
ble CS schools have indeed not been able 
to place their limited “merchandise.” 


Max Schindler 
Prime Technology 
Boonton, New Jersey 
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The 

Masters 

of 

Software 

Engineering 

At Wang Institute, you’ll 
find a small community 
of professionals working 
toward a common goal: 
leadership positions in 
software engineering and 
project management. 

Our Master of Software 
Engineering program gives 
you a practical foundation 
in the technology, method¬ 
ology and management of 
software development. We 
provide you with resources 
like a comprehensive curric¬ 
ulum, a dedicated faculty, 
and a sophisticated comput¬ 
ing facility set in the country 
north of Boston. 

You can attend classes on a 
part-time basis while work¬ 
ing, or earn your Masters 
degree in 12 months as a 
full-time student. For more 
information, call or write to 
Janis Ackerman or Phyllis 
DiCostanzo at 617-649-9731, 
Wang Institute, Tyng Road, 
Tyngsboro, MA 01879. 


Wang Institute 

OF GRADUATE STUDIES 


Your current status: 

□ Software Professional 
□ Student □ Other 
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Design 

Decisions 



Ten superminicomputer processors 
for your desk will come packaged as 
a VLSI workstation called SPUR, 
once the team at UC Berkeley finds a 
partner to transfer their upcoming 
prototype to industry. 


S PUR (Symbolic Processing Using 
RISCs) is a multiprocessor work¬ 
station being developed at the 
University of California at Berkeley to 
conduct parallel processing research. Its 
development is part of a multi-year effort 
to study hardware and software issues in 
multiprocessing, in general, and parallel 
processing in Lisp, in particular.* This 
article concentrates on the initial ar¬ 
chitectural research and development of 
SPUR. 

Two key observations motivated the 
architecture of SPUR. First, although 
parallel processing hardware has existed 
for many years, these systems have been 
difficult to program. Often the architec¬ 
tural features of a parallel machine, par- 


"We distinguish between multiprocessing and paral¬ 
lel processing. Multiprocessing occurs whenever two 
or more processors in a computer are used at the 
same time. Parallel processing occurs when they are 
cooperating on the same job. All parallel processing 
is multiprocessing, but not vice versa. 


ticularly the interconnection network 
between the processors, had to be consid¬ 
ered during programming. 1 The com¬ 
plexity of managing such details has left 
parallel processing a novelty, rather than 
the norm. Consequently, we are design¬ 
ing SPUR to simplify parallel processing 
software by providing a single global 
memory that can be shared, with 
uniform access times. Implementing a 
high-performance shared memory sys¬ 
tem increases the system’s hardware 
complexity, but we believe the shared 
memory software model facilitates the 
rapid development of parallel processing 
software and permits implementation of 
other, more restricted, sharing para¬ 
digms (such as message passing). 

Second, hardware is more difficult to 
design, construct, debug, and modify 
than most software. Consequently, most 
SPUR hardware features are simple, fre- 
quently-used primitives. We migrate fea¬ 
tures from software into hardware only if 


doing so achieves a significant perfor¬ 
mance gain in return for reasonable design 
and implementation costs. The complex 
hardware features included in SPUR 
either facilitate parallel processing (for 
example, hardware-based cache consis¬ 
tency) or make large contributions to 
performance (for example, the instruc¬ 
tion buffer and Lisp data-type tags). 

The SPUR processor extends the work 
of reduced instruction set computers 
(RISC) 2 and Smalltalk on a RISC 
(SOAR) 3 with some special support for 
two emerging standards: Common Lisp 4 
and IEEE Standard 754-1985 for binary 
floating-point arithmetic. 5 We designed 
the Lisp and floating-point support so 
that software that does not use these ex¬ 
tensions is not penalized by their exis¬ 
tence. Thus, the SPUR processors are 
general-purpose processors with some 
support for Lisp and floating-point, 
rather than special-purpose Lisp or float¬ 
ing-point processors. 
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The SPUR project consists of SPUR 
workstation development and research 
efforts in integrated circuits, computer 
architecture, operating systems, and pro¬ 
gramming languages. Integrated circuit 
researchers are examining complemen¬ 
tary metal oxide semiconductor (CMOS) 
design styles, the effects of scaling very 
large scale integration (VLSI) circuits, 
and control and clocking issues. Com¬ 
puter architecture researchers are study¬ 
ing multiprocessor address trace analy¬ 
sis, cache consistency, virtually-tagged 
caches, in-cache address translation, mul¬ 
ti-level cache design, coprocessor inter¬ 
faces, instruction delivery, Lisp hardware 
support, and floating-point implementa¬ 
tions. Operating systems researchers are 
investigating network file systems, net¬ 
work page servers, the effects of large 
physical memories on virtual memory im¬ 
plementations, and workload distribu¬ 
tion. Programming languages researchers 
are examining parallel garbage collection 
algorithms, techniques for specifying par¬ 
allel programs, and methods of compiling 
parallel Lisp programs. 



Figure 1. SPUR workstation system. SPUR is a shared-bus multiprocessor. The sys¬ 
tem supports several identical high-performance processors on a modified Texas 
Instruments NuBus. Each of the custom processors contains a large cache to reduce 
the bandwidth required from the bus and shared memory. 


System overview 

SPUR contains 6 to 12 high-perfor¬ 
mance homogeneous processors (see Fig¬ 
ure 1). The number of processors is large 
enough to permit parallel processing ex¬ 
periments, but small enough to allow 
packaging as a personal workstation. 

The processors are connected to each 
other, to standard memory, and to 
input/output devices with a modified Nu¬ 
Bus. Using a commercial bus reduces pro¬ 
totype design time by allowing the use of 
standard subsystems and memory. 

SPUR supports sharing between coop¬ 
erating processes with a global, shared 
memory. System performance is im¬ 
proved by placing 128K-byte caches on 
each processor to reduce bus traffic, 
memory contention, and effective mem¬ 
ory access time. Each of these caches is 
accessed with virtual addresses, rather 
than physical addresses, so that address 
translation is not necessary on cache hits. 
On cache misses, virtual addresses are 
translated into physical addresses before 
accessing shared memory. 

The caches are supplemented with 
hardware that guarantees that copies of 
the same memory location in different 
caches always contain the same data. 
This enables programmers to write soft- 
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Figure 2. SPUR processor board. A SPUR processor is implemented on a single board 
that contains three custom VLSI chips and 200 standard chips. The three custom 
chips are the cache controller (CC), the CPU, and the floating-point coprocessor 
(FPU). Standard chips are used to hold the state, address tags, and data of the cache 
(cache RAMs), and to connect functional components together (not shown). Memory 
addresses and data are handled on separate buses. The address bus is 38 bits wide to 
accommodate global virtual addresses. The data bus is 64 bits wide to handle floating¬ 
point data. The FPU tracks instructions executed by the CPU with a special 22-bit 
connection. Some infrequently used data paths are not shown here. 


ware without considering the existence of 
cache memory. 

The high level architecture of SPUR 
(multiple processors communicating 
through shared memory over a common 
bus) is comparable to a few commercial 
multiprocessors, such as the Sequent 
Balance 8000 and the Elxsi 6400. How¬ 
ever, since neither commercial machine 
was intended to be a low-cost worksta¬ 
tion, the differences in their more de¬ 
tailed architectures are fairly significant. 

The Sequent is built from 10-MHz Na¬ 
tional Semiconductor 32032 central pro¬ 
cessor unit chips communicating over a 
pipelined, packet-switched bus. The high 
speed of the bus (relative to that of the 
CPUs) enables the Sequent to support 
between 2 and 12 processors with rela¬ 
tively small caches (8K bytes) and a write- 
through write policy. 

The Elxsi 6400 processors and bus in¬ 
terface logic have been implemented with 
emitter-coupled logic (ECL) gate arrays. 
The bus is also packet switched, with a 25 
ns cycle time, and easily supports up to 
eight CPUs. Cache consistency in the 
16K-byte, two-way set associative caches 


is maintained by a variety of software 
techniques. 6 

Processor overview 

A SPUR processor is a general- 
purpose RISC processor that provides 
support for Common Lisp and IEEE 
floating-point. A processor is imple¬ 
mented on a single board with about 200 
standard chips and three custom two- 
micron CMOS chips: the cache con¬ 
troller (CC), the CPU, and the floating¬ 
point coprocessor (FPU). (See Figure 2.) 

The CC chip manages the cache. This 
includes handling cache accesses by the 
CPU, performing address translation, 
accessing shared memory over the SPUR 
bus, and maintaining cache consistency. 

The CPU chip is a custom VLSI chip 
based on the Berkeley RISC architec¬ 
ture. 7,2 Like the RISC II implementa¬ 
tion, 8 the SPUR CPU uses a simple 
uniform pipeline, hard-wired control, 
and a large register file. It attempts to 
issue a new instruction every cycle. The 
SPUR CPU differs from RISC II be¬ 


cause of the addition of a 512-byte in¬ 
struction buffer, a fourth execution pipe¬ 
line stage, a coprocessor interface, and 
support for Lisp tagged data. 

The final custom chip is the floating¬ 
point coprocessor, which supports the 
full IEEE standard 754 for binary float¬ 
ing-point arithmetic without microcode 
control. The FPU executes common 
operations under hard-wired control. In¬ 
frequent operations cause traps and are 
handled by software. 

Initial results with small Lisp bench¬ 
marks show that a single SPUR pro¬ 
cessor is comparable to the VAX 8600 
CPU and the Symbolics 3600 CPU 9 (see 
Table 1). 

The memory system 

The SPUR memory system appears to 
software as flat, global, shared memory, 
but is implemented with a hierarchy of 
levels. The fastest level, the instruction 
buffer, is an instruction cache on the 
CPU chip. The second level, the cache, is 
a cache on the processor board for in¬ 
structions and data. If information is not 
found in either of these local memories, 
then the virtual address is translated into 
a physical address and a global memory 
access is made via the SPUR bus. Both 
the virtual and physical addresses are 
transmitted on SPUR bus transactions. 
Off-the-shelf memory and I/O control¬ 
lers use the physical address. Other cache 
controllers use the virtual address to 
preserve software’s view of global, 
shared memory. 

The memory model. SPUR presents 
software with a 256G-byte global virtual 
address space, divided into 256 lG-byte 
segments. Every process has direct access 
to four segments via a 32-bit process-spe¬ 
cific virtual address. (The segments of a 
SPUR process resemble VAX-11 regions.) 
This address is mapped into a 38-bit global 
virtual address in parallel with the first part 
of a cache access (Figure 3). 

A process’s four segments will normal¬ 
ly be used for system code and data, user 
code, a private stack, and a shared heap. 
Two or more processes that want to share 
information must share an entire seg¬ 
ment. Support for sharing at the granu¬ 
larity of a segment is a compromise be¬ 
tween using a single shared virtual- 
address space and supporting sharing of 
arbitrary-size objects at this level. We re¬ 
jected the former extreme because it does 
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not permit hardware-guaranteed isola¬ 
tion of unrelated jobs. We rejected the 
latter because it is not clear that the 
benefits justify the hardware cost. 

The memory system, except the in¬ 
struction buffer, uses global virtual ad¬ 
dresses instead of process-specific virtual 
addresses so that information can be 
manipulated independently of processor 
and process identifiers. For this reason, 
cache flushes are not necessary on a con¬ 
text switch or when a process is migrated 
to a different processor. 

We set the global virtual address space 
limit of 256 segments by balancing the 
projected needs of software against the 
cost of hardware implementation. The 
segment limit does not constrain the 
number of lightweight processes, 10 
which use the address space of their 
parent. This is important because we ex¬ 
pect the parallel processing Lisp system 
to make extensive use of lightweight pro¬ 
cesses. This limit does, however, restrict 
the number of concurrently active 
heavyweight processes (such as Unix 
shell processes) depending on the num¬ 
ber of segments shared. The limit ranges 
from 64 processes with no sharing to 253 
processes with three segments shared. 

The instruction buffer: an on-chip in¬ 
struction cache. The instruction buffer is 
a 512-byte instruction cache on the CPU 
chip. It reduces contention for the cache 
so that data references can use the single 
cache port without stalling the execution 
pipeline. By enabling instruction fetches 
and data references to be satisfied in par¬ 
allel, the instruction buffer creates the il¬ 
lusion of a second cache port. 

The instruction buffer also reduces ef¬ 
fective instruction access time. This ef¬ 
fect has little importance in SPUR 
because the cache can be accessed in ap¬ 
proximately one cycle. Nevertheless, this 
effect will become increasingly impor¬ 
tant as technological improvements 
reduce cycle times faster than inter-chip 
communication times, thereby making it 
difficult to access off-chip caches in a 
single cycle. 

The instruction buffer caches 128 
32-bit instructions in 16 direct-mapped 
blocks. Each block contains eight in¬ 
structions, divided into eight single¬ 
instruction sub-blocks 11,12 (see Figure 
4). Preliminary estimates show that the 
instruction buffer satisfies at least 75 per¬ 
cent of instruction fetches without cache 
accesses. 13 


Table 1. Gabriel benchmark results. 

This table presents execution times for Gabriel benchmarks on the DEC 
VAX 8600, Symbolics 3600 with instruction fetch unit, and a single SPUR pro¬ 
cessor. The times for the 8600 and the 3600 are from Gabriel’s Performance and 
Evaluation of Lisp Systems . 10 The preliminary SPUR times are gathered with a 
functional-level simulator of a single processor, assuming a 150-ns cycle time, 
single-cycle access to a 128K-byte cache, and 15-cycle cache miss time. 

The last two columns compare SPUR with the 8600 and 3600. SPUR is 
slower for the ratios shown in bold. The geometric mean is used to combine the 
ratios in a manner that gives each benchmark equal weight. Garbage collection 
time is not included for any of the machines. The 8600 results were gathered 
with data-type declarations to reduce run-time type checking. 

Execution time (seconds) Execution time ratio 

Gabriel DEC Symbolics SPUR 8600/ 3600/ 

benchmark 8600 3600 (projected) SPUR SPUR 
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Figure 3. Virtual memory structure. All processes access virtual memory using a 32-bit 
process-specific virtual address. This address is converted into a 38-bit global virtual 
address during the cache lookup. The high-order two bits of the process-specific vir¬ 
tual address are used to select one of four segments from the 256 segments (eight bits) 
in the global virtual address space. The other 30 bits are used directly for the displace¬ 
ment within the selected lG-byte segment. 
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Figure 4. Cache block with sub-blocks. A conventional cache block (top) has three parts: the cache state bits (labeled bv for block 
valid bits), the address tag, and the cache data block. The state bits record whether the information in the block is valid (or dirty for 
a data cache); the address tag holds the block’s memory address; and the data area holds the information cached. The instruction 
buffer’s block (bottom) is divided into eight single-instruction sub-blocks (labeled instruction-0 to -7). Additional state bits, called 
word valid bits (labeled wv), are associated with each instruction so that only a single instruction, instead of the entire block, must 
be loaded on a miss. 


The instruction buffer handles misses 
differently than most caches. Instead of 
loading an entire block on each miss, it 
loads only the fetched instruction. The 
advantage of fetching single-instruction 
sub-blocks is that a miss can be com¬ 
pleted more quickly. The disadvantages 
are that the state bits must be extended to 
include a valid bit for each sub-block in 
the block and control must handle both 
block misses (the address tag does not 
match) and sub-block misses (the tag 
matches, but the sub-block is not valid). 
We believe the advantage of using sub¬ 
blocks justifies the small increase in chip 
area and design time needed to imple¬ 
ment them. 12 

The instruction buffer miss ratio is 
reduced by using prefetching from the 
cache to create the illusion that the entire 
32-byte block is loaded on a miss. For ex¬ 
ample, near the end of a miss to the third 
instruction in a block, the prefetcher at¬ 
tempts to prefetch instructions 4, 5, 6, 7, 
0,1, and 2. Unless prefetches are blocked 
by data references, instructions 4 
through 7 will be loaded into the instruc¬ 
tion buffer before they will be accessed 
by the execution unit. If the execution 
unit fetches an instruction that misses in 
another block, the prefetcher begins 
prefetching in that block even if the old 
block is not completely loaded. The 
prefetcher never hurts performance be¬ 
cause it never replaces instructions 
already in the instruction buffer or in¬ 
terferes with data references or instruc¬ 
tion fetch misses. 

The cache. A 128K-byte cache for in¬ 
structions and data on every processor 
board reduces SPUR bus traffic. For a 
fixed transfer size, bus traffic can be re¬ 


duced by increasing a cache’s size or 
complexity (degree of associativity). 14 
Memory chip technology makes it possi¬ 
ble to build larger, unsophisticated 
caches with fewer packages than smaller, 
more complex ones. Consequently, the 
SPUR cache is simple, although larger 
than the caches in most mainframes. It is 
direct-mapped, does not permit unaligned 
accesses, and uses 32-byte blocks to trans¬ 
fer and cache information. It does not 
prefetch blocks from memory, because 
prefetching increases bus traffic. Instruc¬ 
tion buffer prefetches that miss in the 
cache are terminated without a memory 
reference. Simulation results find cache 
miss ratios under two percent (see the col¬ 
umn labeled “Ideal” in Table 2). 13 

The SPUR cache associates virtual ad¬ 
dress tags, rather than physical address 
tags, with blocks of data. A virtually- 
tagged cache is accessed directly, without 
address translation. In contrast, physi¬ 
cally-tagged caches require that address 
translation be done before or in parallel 
with the first part of a cache lookup. 

Unfortunately, schemes that permit 
parallel address translation limit the size 
of the cache, constrain the mapping of 
virtual pages to physical page frames, or 
require support for fast reverse mapping 
(translating physical addresses back to 
virtual addresses). For a physically- 
tagged cache access to proceed in parallel 
with address translation, the cache must 
be indexed with bits that do not change in 
address translation. These bits are usual¬ 
ly within the page offset, because systems 
designers are unwilling to constrain the 
mapping of virtual pages to physical page 
frames so that some bits of the virtual 
page number do not change. The bits 
used to index a cache will be within the 


page offset only if the cache size divided 
by its degree of associativity is equal to or 
smaller than the page size. Consequently, 
we believe that as cache sizes increase, 
virtually-tagged caches will become more 
commonly used. 

Another benefit of virtually-tagged 
caches is that the address translation time 
does not affect cache hit time since ad¬ 
dress translation is necessary only for 
cache misses. Therefore, address transla¬ 
tion can be done more slowly in a system 
with a virtually-tagged cache than in one 
with a physically-tagged cache where ad¬ 
dress translation must be less than the 
cache access time. SPUR exploits this 
freedom by eliminating the traditional 
translation buffer. 

Most commercial computers use phys¬ 
ically-tagged caches rather than virtually- 
tagged caches. This is because current 
commercial architectures include three 
features that make the implementation 
of virtually-tagged caches difficult. The 
rest of this section explains how the use 
of a single, segmented virtual address 
space and a dual-address bus allows 
SPUR to avoid the problems commercial 
implementors have encountered. 

Problems implementing virtually- 
tagged caches. The first problem is 
handling the virtual address space 
changes associated with most context 
switches. A virtual address space change 
means that virtual addresses refer to new 
locations. A virtually-tagged cache must 
guarantee that references to the new vir¬ 
tual address space are not accidentally 
satisfied by data from the old locations. 

Address space changes can be handled 
in a virtually-tagged cache by flushing 
old data on every context switch or by at- 
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taching address space identifiers to 
cached data. The former method reduces 
performance for large caches. The latter 
increases the size of cache address tags 
and can increase cache complexity if 
synonyms, described in the next para¬ 
graph, are allowed. SPUR avoids the 
problems of virtual address space 
changes by using a global segmented vir¬ 
tual address space that does not change 
after a context switch. This results in an 
increase in tag size comparable to adding 
address space identifiers, but permits 
sharing without synonyms. 

The second problem for implementors 
of virtually-tagged caches is that of cor¬ 
rectly handling synonyms (aliases). 
Synonyms are multiple virtual addresses 
that map to the same physical address. 
They present a problem when the same 
physical location is read into a virtually- 
tagged cache twice with two different vir¬ 


tual addresses, and then one of the copies 
is modified. To preserve the program¬ 
mer’s model of memory, the virtually- 
tagged cache must guarantee that a read 
with the other virtual address gets the 
new value. 

This problem is hard to solve in a 
single virtually-tagged cache, and even 
harder to solve in a multiprocessor sys¬ 
tem with many such caches. SPUR 
avoids this problem by disallowing 
synonyms. Instead, two or more pro¬ 
cesses share information by putting it in a 
shared segment at the same displacement 
(the same global virtual address). Soft¬ 
ware resolves the location of static, 
shared information at load-time and uses 
operating system calls that allocate new 
storage to establish the location of dy¬ 
namic, shared information. 

The third problem with virtually- 
tagged caches is updating cache data that 


is being written by an I/O device using a 
physical address. In the long run, the 
problem of mapping physical I/O ad¬ 
dresses back into virtual addresses can be 
avoided by having both I/O devices and 
memory use virtual addresses. 

We rejected this approach in SPUR be¬ 
cause we wanted to use off-the-shelf, 
physically-addressed memory boards. 
Instead, the SPUR bus associates a virtu¬ 
al and a physical address with most bus 
transactions. The virtual address is used 
by other cache controllers for maintain¬ 
ing cache consistency. The physical ad¬ 
dress is used by memory and I/O control¬ 
lers. The reverse mapping problem is 
solved by not permitting an I/O buffer to 
be cached while it is being written by an 
I/O device. The operating system can 
guarantee this by putting the buffer on a 
non-cacheable page or by flushing the 
buffer from all caches before I/O begins. 


Table 2. In-cache address translation versus translation buffers. 

This table compares SPUR in-cache translation with translation using translation buffers. The metric used, the aggregate 
miss ratio, is the number of cache misses plus the number of translation misses divided by the number of processor 
references. Smaller values of this metric predict better performance if the cost of cache and translation misses are com¬ 
parable (as they are in SPUR). Numbers in parentheses give the magnitude of the aggregate miss ratio relative to the SPUR 
in-cache aggregate miss ratio. Three comparisons are made. The first two are application programs running on a VAX-11 
under Unix 4.2 BSD. Liszt is an address trace of the Franz Lisp compiler compiling a portion of itself. Vaxima is a trace of 
an algebraic system executing a representative repertoire of commands. The final trace, MVS, is a series of system calls exe¬ 
cuted by the MVS operating system on an Amdahl 470 machine. 

This table assumes that each of the translation mechanisms are invoked only after a reference misses in the SPUR cache, 
which is 128K bytes large, has 32-byte blocks, and is direct-mapped. The first alternative, Ideal, sets the aggregate miss ratio 
to the cache miss ratio and assumes translation without cost. The second alternative, SPUR in-cache, uses the cache to hold 
PTEs for 4K-byte pages. The last three alternatives use translation buffers to do translation. The third uses half of the 
VAX-11/780 translation buffer (128 entries, 512-byte pages, and two-way set-associative) because the VAX-11 restricts pro¬ 
cess and system entries to different halves of the buffer. The fourth uses the VAX 8600 translation buffer (512 entries, 
512-byte pages, and one-way set-associative) in the same manner. The last alternative uses the IBM 3033 translation 
lookaside buffer (128 entries, 4K-byte pages, two-way set-associative). In all but one case, shown bold, SPUR in-cache 
translation performs slightly better than systems that include translation buffer hardware. 


Aggregate miss ratio with identical caches 
but alternative address translation mechanisms 
metric: (cache misses + translation misses) / references 


Trace 



SPUR cache plus translation via: 



Ideal 

SPUR in-cache 

VAX-11/780 TB 

VAX 8600 TB 

IBM 3033 TLB 
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0.00584 
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(1.000) 
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The latter does not imply a complete 
cache flush because the cache supports 
flushing of individual blocks. 

Address translation without a transla¬ 
tion buffer. The mapping of virtual ad¬ 
dresses to physical addresses is usually 
maintained in a structure called a page 
table. 15 The appropriate page table entry 
(PTE) is referenced during the address 
translation process. 

Most computers use a special-purpose 
cache for PTEs, called the translation 
buffer, to reduce address translation 
time. Translation buffers are important 
in systems with physically-tagged caches, 
which require address translation on 
every reference. 

Fast address translation is less impor¬ 
tant with SPUR’s virtually-tagged cache, 
because address translation is necessary 
only on cache misses. Consequently, 
rather than using a translation buffer, the 
SPUR address translation mechanism al¬ 
ways uses cache accesses to reference 
PTEs logically in shared memory. 16 

The performance of SPUR in-cache 
translation compares to that with fixed- 
si/e translation buffers. Moreover, in¬ 
cache translation has two advantages. 
First, it avoids the design and implemen¬ 
tation costs of a translation buffer. Sec¬ 
ond, it keeps PTEs consistent (transla¬ 
tion buffer consistency) without special 
support. 

Because traditional translation buffers 
are merely special-purpose cache memo¬ 
ries, multiprocessors that use them suffer 
from a translation consistency problem 
(analogous to the data cache consistency 
problem). Solving this problem requires 
an increase in either hardware or operat¬ 
ing system complexity. The SPUR in¬ 
cache translation mechanism avoids this 
problem by eliminating the translation 
buffer and storing the PTEs only in the 
cache, where they are kept consistent by 
the regular consistency mechanism. 

In-cache address translation is invoked 
when data referenced is not in the cache. 
(In this discussion, data refers to instruc¬ 
tions and data in contrast to address 
translation information such as PTEs.) 
The cache controller performs address 
translation with the following steps. 
First, a page table base register and the 
virtual address of the data are used to 
construct the virtual address of the PTE. 
Second, the PTE is read from the cache. 
Third, the physical page address in the 
PTE and the page offset from the origi¬ 
nal virtual address are combined to form 


the physical address of the data. Fourth, 
a SPUR bus access for the data is made 
with both the virtual and physical ad¬ 
dresses. Last, the data is loaded into the 
cache and passed on to the CPU. 

On rare occasions, the PTE reference 
will also miss in the cache. Since SPUR 
places the first level of page tables in 
pageable virtual memory, a second trans¬ 
lation effort is necessary to service the 
first-level PTE miss. 

The second level of page tables is also 
in virtual memory and thus may be found 
in the cache. This level, however, is in 
nonpageable virtual memory at known 
locations. The physical addresses of sec¬ 
ond-level PTEs are computed by the 
cache controller to end the address trans¬ 
lation process if the cache access for the 
second-level PTE misses. SPUR uses the 
two-level paging mechanism to reduce 
the physical memory dedicated to PTEs 
from 256M bytes to 256K bytes. 

In-cache address translation works well 
for the traces shown in Table 2. Transla¬ 
tion performance with in-cache transla¬ 
tion is comparable to that achieved with 
translation buffers. In addition, other 
results show that the presence of PTEs in 
the cache does not significantly affect 
cache performance for data (non-PTE) 
references. The data miss ratio for Vax- 
ima increased by only 0.00004, from 
0.01844 to 0.01848. The increase for MVS 
was larger than with Vaxima, but still not 
significant (0.00142, from 0.01677 to 
0.01819). 

Cache consistency hardware. The 
problem of maintaining the shared mem¬ 
ory model in multiprocessor systems with 
cache shared, writable data is referred to 
as the cache consistency or cache coher¬ 
ency problem. Inconsistencies arise when 
two or more processors have copies of 
the same shared memory location in their 
private caches, and one processor modi¬ 
fies the location but fails to communicate 
the change to the other processors. 

Cache consistency algorithms prevent 
the old data, called stale data, from being 
used. The two approaches traditionally 
used are (1) to update main memory and 
cause cache invalidations on each write, 
or (2) to use software assists. The first ap¬ 
proach, called write-through with invali¬ 
dation, generates bus traffic proportion¬ 
al to the number of writes. This seriously 
degrades performance in a system with 
several high-performance processors. 17 
The second approach requires software 
to identify whether data is potentially 


shared and makes use of noncacheable 
pages or write-through with invalidation 
to keep that data consistent. This gener¬ 
ates more bus traffic than our approach 
for unrestricted sharing, because bus 
transactions are generated on many ref¬ 
erences to shared pages even if most of 
the data is not in simultaneous use. 

Other researchers are currently investi¬ 
gating how to improve the effectiveness 
of the software approach by using syn¬ 
chronization primitives to delay the 
invalidation of stale data. 18,19 The prin¬ 
cipal weakness of the software approach 
is that it may require extra effort from 
the programmer, possibly discouraging 
the development of parallel processing 
software. 

The cache consistency algorithm used 
in SPUR, called Berkeley Ownership, is 
based on the concept of ownership of 
cache blocks. 20 The responsibility for 
maintaining consistency is distributed 
among the caches. If a cache owns a 
block, then no copies of the block occur 
in any other caches. The owner may up¬ 
date the cached entry locally without 
broadcasting its actions. If a cache does 
not own a block, it must first obtain 
ownership before it can update the 
block. Ownership is obtained by a broad¬ 
cast to other caches, causing them to 
invalidate their copies of the block. In 
addition to the local update privilege, 
ownership carries the obligation to up¬ 
date main memory on block replacement 
(copy-back) and the responsibility of 
overriding main memory if another 
cache requests the block. 

SPUR implements Berkeley Owner¬ 
ship with standard memory, a dual-ad- 
dress bus, and snooping caches. The bus 
broadcasts ownership requests and trans¬ 
fers cache blocks. Most bus transactions 
begin with a type field (such as read or 
read-for-ownership) and a block address 
(both virtual and physical), and end with 
a data transfer. 21 

Each processor cache controller is sup¬ 
plemented with hardware, called the 
snoop, that monitors the bus for trans¬ 
actions involving blocks that it has 
cached. The snoop compares the virtual 
addresses of all bus transactions with a 
second copy of the cache’s address tags. 
If a match occurs, the snoop may have to 
invalidate its copy of the block or over¬ 
ride main memory and provide the data 
to complete the bus transaction. The lat¬ 
ter action only occurs for blocks that 
have been modified and are simulta¬ 
neously shared by processes on more 
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Figure 5. SPUR registers. SPUR’s registers divide into three groups: general purpose, 
special, and floating point. The general-purpose registers are organized into fixed-size 
overlapping windows so that the output registers of one window become the input 
registers of the next window after a procedure call. Only one 32-register window is 
visible at a time. The entire general-purpose register file contains eight windows (not 
shown) for a total of 138 registers. The general-purpose registers are 40 bits wide, con¬ 
sisting of an 8-bit tag and 32 bits of data. The special registers include the user and 
kernel processor status words, register window pointers, and several program 
counters. The floating-point registers are 87 bits wide to accommodate SPUR’s 
representation of IEEE extended-precision numbers. The representation includes a 
three-bit type tag to simplify detection of infrequent floating-point types (such as 
Not-a-Number). The 15 floating-point registers and the floating-point processor 
status word (a special register) are implemented on the FPU chip rather than on the 
CPU chip to improve operand access time for floating-point instructions. Multiple 
windows of these registers were not implemented because of insufficient FPU chip 
area. 


than one processor. While we have little 
data on sharing, we expect this to occur 
on a small fraction of all transactions. 

Berkeley Ownership, implemented in 
hardware with snooping caches, serves 
the goals of SPUR in several ways. First, 
it preserves the shared memory model. 
This model facilitates parallel processing 
experiments by providing a simple, flexi¬ 
ble mechanism for sharing data between 
processes. Second, it simplifies parallel 
processing software by relieving pro¬ 
grammers of the responsibility of under¬ 
standing shared caches. Third, the Berke¬ 
ley Ownership protocol has good mul¬ 
tiprocessor performance because it can 
be restricted to generate extra bus trans¬ 
actions only when two or more pro¬ 
cessors are simultaneously accessing 
writable shared data. For example, our 
protocol allows semaphores to be cached. 
No bus traffic is needed to modify a 
semaphore if only one process happens to 
be using the semaphore for some period 
of time, or if all the processes using the 
semaphore are on the same processor. 
Other methods generate bus transactions 
after shared data has been modified even 
if no processes on other processors are 
trying to access the same data. Fourth, 
our protocol yields good uniprocessor 
performance. When no interprocessor 
sharing can occur, no consistency¬ 
preserving bus transactions will be made. 
Fifth, the algorithm is not difficult to im¬ 
plement. It requires an additional state 
machine in the cache controller, two ad¬ 
ditional state bits for each 32-byte cache 
block, a second copy of all cache state 
bits and address tags, and a change to the 
system bus to permit snooping. It does 
not require centralized control or any 
memory board modifications. 

The CPU and floating¬ 
point coprocessor 

The SPUR CPU design evolved from 
the RISC II design. 8 Like RISC II, 
SPUR has a streamlined instruction set 
and a large register file with multiple, 
overlapping register windows to speed up 
procedure calls. For several reasons, the 
instruction set is well-suited for a high- 
performance VLSI implementation with¬ 
out microcode. First, the instructions are 
easy to decode because of their fixed size 
and few formats. Second, computational 
instructions operate exclusively on 
registers, while memory can be accessed 


only with load and store instructions. 
Register-to-register instructions execute 
quickly and deterministically because 
they cannot generate cache misses or page 
faults once they begin execution. Third, 
the instructions perform simple opera¬ 
tions implemented in a short, uniform 
pipeline. Every instruction uses a par¬ 
ticular resource in the same pipeline 
stage. For example, all SPUR instruc¬ 
tions use the arithmetic and logic unit 
(ALU) to combine operands or calculate 
an effective address in the second stage of 
the pipeline. This simplifies the hardware 
by predetermining the scheduling of 
resources. 

The differences between SPUR and 
RISC II are products of technological 


improvements and the new goals of sup¬ 
porting Lisp and floating-point arith¬ 
metic. Technological improvements in 
the past few years have increased the 
number and speed of transistors possible 
on a VLSI chip. In SPUR, the additional 
transistors are used in an on-chip instruc¬ 
tion cache, for tagging Lisp data, and in 
a low-overhead interface to a floating¬ 
point coprocessor. 

General-purpose features 

The register set. The SPUR register 
set, shown in Figure 5, includes 32 gener¬ 
al-purpose registers. Like the RISC II 
chip, the SPUR CPU contains several 
copies of the general-purpose register set 
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Figure 6. RISC II and SPUR pipelines. RISC II used a three-stage pipeline (top) that 
required the pipeline to stall one cycle on every data memory reference so that precise¬ 
ly one memory reference (instruction fetch or data access) was done every cycle. The 
first stage fetched the next instruction from memory; the second read two registers 
and performed an ALU operation; the final stage wrote the result into a register. 

SPUR uses a four-stage pipeline (bottom) so that an instruction can be issued every 
cycle. Memory-accessing instructions use the additional stage to do a cache access. 
Register-to-register instructions do nothing in the additional stage. All instructions 
write the register file in the fourth stage to guarantee that no two instructions try to 
write at the same time. Pipeline hardware guarantees that the result of a register-to- 
register instruction can be used by the subsequent instruction even though the result 
has not yet been written into the register file. However, software must guarantee that 
the result of a load instruction is not used by the instruction that (dynamically) follows 
the load. 


(not shown in Figure 5) so that these reg¬ 
isters do not have to be saved in memory 
and restored on most procedure calls and 
returns. In addition, the register win¬ 
dows for a caller and a callee overlap by 
six registers so that most arguments and 
returned values can be passed in-place in 
registers instead of in memory. For both 
reasons, overlapped register windows 
reduce the time required for procedure 
calls and returns. The primary cost of the 
multiple register sets is a significant 
amount of chip area and, to a lesser ex¬ 
tent, slower register access time and in¬ 
creased process switching overhead. 

The execution pipeline. The SPUR 
execution pipeline is one stage longer 
than the three-stage RISC II pipeline (see 
Figure 6). RISC II could issue a register- 
to-register instruction every cycle. It used 
resources efficiently: in every cycle two 
registers were read, one was written, the 
ALU was utilized, and the path to mem¬ 
ory was used to fetch an instruction. Un¬ 
fortunately, this arrangement left no 
memory bandwidth for data references. 
Consequently, loads and stores had to 
stall the pipeline one cycle to use the path 
to memory. Thus, RISC II did a memory 
reference per cycle rather than complet¬ 
ing an instruction per cycle. 


SPUR uses an instruction buffer and a 
four-stage pipeline to attempt to issue 
and complete an instruction every cycle. 
The instruction buffer satisfies most in¬ 
struction fetches without cache accesses. 
The new pipeline stage allows memory 
referencing instructions to make cache 
accesses without stalling the pipeline, but 
forces register-to-register instructions to 
delay their register write for one stage. 
All instructions modify the general-pur¬ 
pose register file in the fourth pipeline 
stage, thereby avoiding write conflicts. 
Internal forwarding is done by the hard¬ 
ware so that the result of a register-to- 
register instruction can be used by the 
next instruction even though that result 
has not yet been written into the register 
file. 

In practice, SPUR will not be able to 
execute one instruction every cycle, prin¬ 
cipally because of instruction buffer and 
cache misses. On simulations with the 
Gabriel benchmarks (see Table 1), SPUR 
executed an instruction every 1.59 cycles 
with instruction buffer and cache miss 
ratios of 14 and 1 percent. Performance 
varied across the benchmarks from 1.03 
to 1.99 cycles per instruction. Larger 
programs are likely to have more cycles 
per instruction because of poorer locality 
of reference. Even if the instruction buf¬ 


fer and cache miss ratio double, however, 
SPUR still executes an instruction every 
2.06 cycles. 

The instruction set. This section 
focuses on a few important decisions in 
the SPUR instruction set. (See Taylor’s 
“SPUR Instruction Set Architecture” 22 
for the complete design.) To simplify de¬ 
coding, all instructions are four bytes 
long and use fixed positions for the op¬ 
code and register specifiers. Most in¬ 
structions use either two source registers 
and one destination register or a source 
register, an immediate constant, and a 
destination register. Table 3 lists the basic 
instruction set, not including instructions 
for Lisp and floating-point operations. 

Memory accesses are made with loads 
and stores. The effective address for a 
load is either the sum of two registers or 
the sum of an immediate displacement 
and a register. SPUR uses a delayed load, 
which requires software to guarantee 
that the result of a load instruction is not 
used by the instruction that (dynamical¬ 
ly) follows the load. Cache misses on 
data references stall the entire pipeline 
and thus are not visible to software. The 
effective address for a store is always a 
register plus immediate displacement, so 
that a two-port register file suffices (one 
register for the address and one for the 
data). A store stalls the execution pipe¬ 
line for one cycle, because less-common 
cache writes take longer than cache 
reads. 

Cache reads access cache data in paral¬ 
lel with examining cache address tags. 
Cache writes begin in a similar fashion, 
but cannot write into a cache block until 
after the address tag has been examined. 
In our initial design, stores did not stall 
the pipeline because we set the cycle time 
to the cache write time. We were able to 
improve performance by reducing the cy¬ 
cle time to the cache read time, thus forc¬ 
ing the less frequent cache writes to take 
two cycles. 

SPUR supports synchronization with 
a test-and-set instruction implemented in 
the cache. Under the best of conditions it 
does not require any bus transactions. To 
simplify the cache interface, SPUR does 
not have load or store instructions that 
manipulate individual bytes. A load-byte 
instruction would increase the cache ac¬ 
cess time, and a store-byte instruction 
would increase cache complexity. In¬ 
stead, byte insert and extract instructions 
assist in loading and storing individual 
bytes. 


16 


COMPUTER 


















SPUR adopted the delayed branch 
from RISC II. The execution of a branch 
instruction on most pipelined processors 
requires that the branch target be fetched 
and the execution pipeline flushed before 
the target instruction is executed. A 
branch instruction on SPUR allows—in 
fact, requires—the next sequential in¬ 
struction to be executed while the branch 


target is fetched. A delayed branch saves 
program execution time if a useful in¬ 
struction can be scheduled in this delay 
slot. Gross found this could be done on 
63 percent of delayed branches dynami¬ 
cally encountered in the traces studied. 23 
Gross also found that delayed branches 
did not significantly increase code size 
since 87 percent of the statically exam¬ 


ined delayed slots contained useful 
instructions. 

SPUR also includes a canceling com¬ 
pare and branch instruction, which dy¬ 
namically turns the instruction in the de¬ 
lay slot into a no-op if the branch is not 
taken. The technique is also being used in 
the Lawrence Livermore S-l AAP. This 
variant of the delayed branch makes it 


Table 3. Basic SPUR instructions. 

This table lists the basic SPUR instruction set. The column Cycles shows the minimum number of cycles consumed by an 
instruction. Many instructions operate on two sources (srcl and ri) and write a result into a destination (dest). Srcl and dest 
are five-bit register specifiers. Ri is either a 5-bit register specifier or a 14-bit signed immediate constant. Rci stands for a five- 
bit register specifier or a five-bit unsigned immediate constant. Pc stands for the program counter. The Action column 
describes what happens in the data portion of the destination and source registers. Exceptional conditions and Lisp tag 
manipulation are described in the SPUR instruction set architecture. 23 


Instruction 

Operands 

Action 

Cycles 

Load/Store 

load _ 32 

dest, srcl, ri 

dest—M [srcl + ri] 

1 

load _ external 

dest, srcl, ri 

dest—external (cache) state 

1 

test_and_set 

dest, srcl, ri 

dest—M (srcl +rij; M [srcl +ri]<00> —1 

2 

store _ 32 

src2, srcl, imm 

src2—M [srcl + imm] 

2 

store _ external 

src2, srcl, imm 

src2—external (cache) state 

1 

Compute 

add, subtract 

dest, srcl, ri 

dest—srcl op ri 

1 

add(no traps) 

dest, srcl, ri 

dest—srcl +ri 

1 

and, or, xor 

dest, srcl, ri 

dest—srcl op ri 

1 

sll, srl, sra 

dest, srcl, ri 

dest—srcl op ri<01:00> 

1 

extract 

dest, srcl, ri 

dest <07:00> —one byte from srcl selected by ri 

1 

insert 

dest, srcl, ri 

dest—ri< 07:00 > inserted into one byte of srcl 

1 

Branch/Jump 

cmp _branch _ delayed 

cond, srcl, rci, offset 

if (srcl cond rci) pc—pc + signed word offset 

1 

cmp _branch _ likely 

cond, srcl, rci, offset 

if (srcl cond rci) pc—pc + signed word offset 
else change next instruction into no-op 

1 

jump 

address 

pc—word address (in same segment) 

1 

jump _ register 

srcl, ri 

pc—srcl +ri 

1 

Call/Return 

call, call_kernel 

address 

increment current window pointer; 
save pc; pc—word address 

1 

return, return_trap 

srcl, ri 

pc—srcl +ri 

decrement current window pointer 

1 

Access Specials 

read _ special 

dest, srcl 

dest—special register srcl 

1 

write _ special 

dest, srcl, ri 

special register dest—srcl +ri 

1 

read _ kernel _psw 

dest 

dest—kernel psw 

1 

write_kernel_psw 

srcl, ri 

kernel psw—srcl + ri 

1 
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Table 4. SPUR Lisp instructions. 


This table lists Lisp instructions. The column Cycles shows the minimum number of cycles consumed by an instruction. 
Load_40 and store_40 move tagged words into and out of registers. Car and cdr are special forms of load_40 that check for a 
proper list element. Read_tag and write_tag move a tag to and from the data part of a register. Compare_and_branch _ 
delayed and compare_and_branch_Iikely, presented in Table 3, compare the tags and values of two Lisp data items. In 
addition, tag_compare_and_branch_delayed and tag_compare_and_branch_likely are available to determine the value of a 
tag (by comparing it with an immediate constant). Compare_and_trap and tag_compare_and_trap are used to test for error 
conditions. 


Instruction 

Operands 

Action 

Cycles 

load_40 

dest, srcl, ri 

dest—M [srcl -t-ri] 

1 

car/cdr 

dest, srcl, ri 

dest—M [srcl -t- ri] 

1 

store _ 40 

src2, srcl, imm 

src2—M [srcl + imm] 

2 

read _ tag 

dest, srcl 

dest<07:00> —srcl tag 

1 

write _ tag 

dest, ri 

dest tag— ri<07:00> 

1 

tag _ cmp _ branch _ delayed 

cond, srcl, tag_imm, offset 

if (srcl < tag >cond tag_imm) 
pc—pc + signed word offset 

1 

tag _ cmp _ branch _likely 

cond, srcl, tag_imm, offset 

if (srcl < tag> cond tag_imm) 
pc—pc + signed word offset 
else change next instruction into no-op 

1 

compare _ and...trap 

cond, srcl, rci 

if (srcl cond rci) trap 

1 

tag _ compare _ and _ trap 

cond, srcl, tag_imm 

if (srcl cond rci) trap 

1 


easier to schedule a useful instruction in 
the delay slot. The natural use of this in¬ 
struction is at the bottom of a loop, with 
the branch target set to the loop’s second 
instruction and the delay slot filled with a 
copy of the loop’s first instruction. 

An arbitrary shift instruction was not 
included, because most shifting done in 
high-level language programs is for ef¬ 
fective address computation in arrays 
and records. 8 SPUR provides shift in¬ 
structions only to shift one bit right and 
one, two, and three bits left. Shift opera¬ 
tions are not needed for integer multipli¬ 
cation or division since these operations 
are done with the FPU. 

Supporting Lisp. The Lisp program¬ 
ming language has some features diffi¬ 
cult to implement efficiently on conven¬ 
tional computers. These include frequent 
function calls and returns, polymorphic 
operations, and automatic garbage col¬ 
lection. Most machines designed to run 
Lisp use a stack-based architecture with 
extensive microcode support (such as the 
Symbolics 3600, 24 LMI Lambda, 25 and 
the Xerox D-Machines. 26 ) Our approach 
emphasizes a simple, regular instruction 
set, overlapping register windows, and 
tagged data. 9 Table 4 lists the instruc¬ 
tions tailored for Lisp. 

Fast function calls and returns are par¬ 
ticularly important for Lisp, because 
Lisp programs are constructed from 


many small functions. SPUR provides 
fast function calls and returns through 
the overlapping register window mecha¬ 
nism. Studies have shown that this mech¬ 
anism, developed for C, effectively 
speeds up Lisp calls and returns. 27 The 
complicated argument options allowed 
by Common Lisp (such as default and 
keyword parameters) are handled by 
software rather than by special-purpose 
instructions or microcode. This ap¬ 
proach increases the size of functions 
that use these options, but ensures that 
simple function calls execute rapidly. 

Tagged architecture. Lisp uses 
polymorphic functions with operands 
whose type is not known until run-time. 
A polymorphic function operates on ar¬ 
guments of more than one data type. 28 
For example, the addition operator (4-) 
is a polymorphic operator in most high- 
level languages because it is defined to 
operate on both integers and floating¬ 
point numbers. Lisp complicates the im¬ 
plementation of polymorphic operations 
because it associates the type of data with 
the data values instead of the program 
variables. For example, a variable is not 
an integer variable, known at compile¬ 
time, but rather a variable that may con¬ 
tain an integer at run-time. When a Lisp 
function is evaluated, the types of oper¬ 
ands must be determined before the ap¬ 
propriate routine is executed. 


SPUR handles polymorphic opera¬ 
tions by manipulating the 6-bit data-type 
tags of operands in parallel with operat¬ 
ing on the 32-bit data values (see Figure 
7). Type checking in SPUR, like several 
other machines, 29,3 assumes that most 
arithmetic operands are integers. For ex¬ 
ample, a polymorphic add operation in 
SPUR is implemented with an add in¬ 
struction that begins by adding the 32-bit 
operands as if they were integers and, in 
parallel, checking the data-type tags to 
verify that they are integers. If both 
operands are integers, the instruction 
finishes by writing the sum into the result 
register. Otherwise, the register write is 
suppressed and the instruction traps to 
software that determines the types of the 
operands and performs the appropriate 
form of addition. 

The power of SPUR to manipulate 
data-type tags is increased by several in¬ 
structions that allow conditional traps 
and branches based on tag values (see 
Table 4). The conditional traps allow ef¬ 
ficient checking of error conditions. Ex¬ 
plicit tag comparison instructions are 
used to implement polymorphic opera¬ 
tions in the more complicated cases not 
handled by the hardware. 

Data-type tags also assist list manipu¬ 
lation, which is fundamental in Lisp. A 
list is a sequence of elements (such as (a b 
c)). The Lisp functions that manipulate 
lists are called car and cdr. Car returns 
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the first element of a list (a) and cdr 
returns the rest of the list ((be)). 

Car and cdr can be implemented with 
load instructions because lists are stored 
as linked lists in main memory. However, 
the semantics of Common Lisp strongly 
encourage generation of an exception if 
the argument of car or cdr is not a list. 
Conventional architectures must execute 
one or more instructions to check this 
condition even though the arguments of 
all car’s and edr’s in a correct program 
are lists. 

SPUR provides a car/cdr instruction 
that checks the data-type tag in parallel 
with the load. A trap is generated if the 
type of the operand is inappropriate. 
This is an ideal use of parallel tag check¬ 
ing because it allows SPUR to execute car 
and cdr at the same speed as a load and 
still generate exceptions on errors. 

SPUR also uses part of the tag field to 
assist in garbage collection. Lisp en¬ 
courages programmers to dynamically 
create and use data structures in memory. 
Automatic garbage collection reclaims 
structures that are no longer in use. This 
feature relieves the Lisp programmer of 
the responsibility of explicitly discarding 
obsolete structures, a task that leads to 
subtle bugs and complicated program¬ 
ming. SPUR stores a two-bit generation 
number in the tag to assist a generation 
scavenging garbage collection algorithm 
(see Figure 7). 3 The algorithm exploits a 
property of dynamic data: new data 
structures are likely to become garbage 
soon and old data structures are likely to 
stay in use. Therefore, most garbage col¬ 
lection activity focuses on the new data. 
The generation number records the num¬ 
ber of garbage collections that an item 
has survived and hence its age. 

Poor data density. We designed the 
SPUR architecture with more emphasis 
on speed and simplicity than concern for 
code or data density. The prototype im¬ 
plementation has particularly poor Lisp 
data density because we decided not to 
build a complete 40-bit system. 

The CPU manipulates 40-bit data (an 
8-bit tag and 32-bit data). That data must 
often be loaded from and stored to the 
cache and the rest of the memory system. 
Three approaches exist for doing this: 

(1) build the whole system with 40-bit 
words, 

(2) allow unaligned cache accesses, or 

(3) place 40-bit words in aligned 64-bit 
words. 


We rejected a 40-bit-word memory sys¬ 
tem because it would preclude the use of 
many off-the-shelf subsystems, which 
would substantially delay completion of 
the prototype. It would also have com¬ 
plicated non-Lisp software in such areas 
as string manipulation and file transfer 
with non-SPUR machines. We rejected 
unaligned cache accesses because of the 
complexity they would add to the cache. 
An unaligned access can cross a cache 
block boundary, possibly forcing the 
cache to handle two cache misses and the 
associated address translation. Conse¬ 
quently, we chose to store 40-bit Lisp 
words in aligned 64-bit words. The other 
24 bits are wasted for tagged Lisp data, 
but not for instructions, data for other 
languages, and some Lisp data struc¬ 
tures. At worst, this storage strategy uses 
60 percent more Lisp data memory than 
the first two schemes, but it allows us to 
explore ideas more quickly by simplify¬ 
ing the design of the prototype. 

Floating-point support. SPUR im¬ 
plements the IEEE 754 binary floating¬ 
point standard 5 with a mixture of hard¬ 
ware and software. Floating-point in¬ 
structions are executed on the floating¬ 
point coprocessor chip (FPU). The FPU 
hardware is optimized to execute com¬ 
mon floating-point operations quickly. 
Effective use of the FPU depends on a 
low-overhead floating-point interface 
and support for concurrent execution of 
floating-point and CPU instructions. 

The SPUR FPU is one of the first im¬ 
plementations of IEEE floating-point 
that does not use any microcoded con¬ 
trol. The Fairchild Clipper CPU also has 
a hard-wired IEEE floating-point unit. 

The floating-point coprocessor. 
Floating-point instructions are either 
register-to-register instructions or loads 
and stores (see Table 5). The register-to- 
register instructions include add, sub¬ 
tract, multiply, and divide. Except for 
multiply (7 cycles) and divide (19 cycles), 
a new floating-point instruction can be 
issued every four cycles. 

Data are transferred between the FPU 
and the cache with floating-point load 
and store instructions. Floating-point 
load instructions convert all single (32 
bits) and double (64 bits) precision num¬ 
bers to extended precision to simplify the 
computational instructions. A convert 
instruction must be executed before a 
store to perform the inverse operation. 
For example, an extended_to_single con¬ 



Figure 7. Lisp tagged data. SPUR 
augments Lisp data words with an eight- 
bit tag that includes a six-bit data-type tag 
and two-bit generation number. Lisp 
integers and characters are represented as 
immediate data. Ail other types of Lisp 
objects are referenced by typed pointers. 
Some of the tag values are used by the 
hardware to do tag checks in parallel with 
data operations. Other tag values are inter¬ 
preted only by software. The generation 
number is used to implement a generation¬ 
scavenging garbage-collection algorithm. 


vert instruction must be executed before 
a store_single instruction. 

The FPU contains 15 87-bit floating¬ 
point registers organized as a single 
register set (see Figure 5). There is no 
analog to the overlapping windows used 
for the general-purpose registers because 
of insufficient FPU chip area to imple¬ 
ment more registers. Furthermore, more 
research is needed to determine how to 
use overlapping windows for floating¬ 
point registers. 

The floating-point register set is in¬ 
dependent of the general-purpose reg¬ 
ister set for four reasons: 

(1) to reduce access time for floating¬ 
point operands, 

(2) to allow more freedom in setting the 
width of floating-point registers, 

(3) to permit concurrent execution of in¬ 
teger and floating-point operations, 
and 

(4) to permit implementation of a 
separate FPU chip. 

SPUR divides the floating-point stan¬ 
dard into two parts. One part is im¬ 
plemented by a set of instructions (see 
Table 5) with hard-wired control and the 
other is implemented by software trap 
handlers. The standard defines six types 
of floating-point numbers: zeros, nor¬ 
malized numbers, denormalized num¬ 
bers, infinities, and two types of Not-a- 
Number symbols. The FPU manipulates 
normalized numbers and zeros entirely in 
hardware. The other four less-common 
types require software assistance. 

The FPU manipulates single (32 bits), 
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Table 5. SPUR floating-point instructions. 

This table lists SPUR floating-point instructions. The column Cycles shows the minimum number of cycles consumed by an 
instruction in normal operating mode. If the FPU and CPU are operated concurrently, a CPU instruction can begin one cycle 
after an FPU instruction has started (see the section labeled Floating-point coprocessor interface). There are floating-point load 
and store instructions for each floating-point format and for integers. Extended-precision numbers require two different loads 
and two different stores to move the first 64 bits and the last 64 bits. Loads do implicit conversion to extended precision, but 
stores merely copy bits. Store_single, store_double, and store_integer must be preceded by the corresponding convert instruc¬ 
tion (such as extended_to_ single). The to_cpu and from_cpu instructions transfer integers directly between the integer and 
floating-point register sets so that the FPU can be used effectively for integer multiply and divide. A conditional branch based 
on floating-point data is done in two steps. First, the CPU executes an fcmp instruction to set a bit in the floating-point pro¬ 
cessor status word (FP PSW). Second, the CPU executes a conditional branch instruction that tests this bit. Most floating¬ 
point operations execute in four cycles using the add/subtract hardware. Multiply and divide use additional special-purpose 
hardware. A sync instruction is used when the CPU and FPU are executing instructions in parallel. It forces the CPU to stop 
executing new instructions until the FPU completes its current instruction (if any). This can be used to guarantee that the store 
of a floating-point result does not begin before the result has been computed. 


Instruction 

Operands 

Action 

Cycles 

load _ single 

dest, srcl, ri 

FPU dest—(convert to extended) M [srcl +ri] 

1 

load _ double 

dest, srcl, ri 

FPU dest —(convert to extended) M [srcl +ri] 

1 

load _ extended 1 

dest, srcl, ri 

FPU dest—M [srcl -t- ri] 

1 

load_extended2 

dest, srcl, ri 

FPU dest—M [srcl + ri] 

1 

load_integer 

dest, scrl, ri 

FPU dest < 63:32 > - M [src 1 + ri] 

1 

store _ single 

src2, srcl, i 

FPU src2—M [srcl+i] 

2 

store_double 

src2, srcl, i 

FPU src2—M [srcl + i] 

2 

store _ extended 1 

src2, srcl, i 

FPU src2—M [srcl+i] 

2 

store_extended2 

src2, srcl, i 

FPU src2—M [srcl+i] 

2 

store _ integer 

src2, srcl, i 

FPU src2—M [srcl+i] 

2 

from_fpu 

dest, src2 

CPU dest —FPU src2<63:32> 

1 

to_fpu 

dest, src2 

FPU dest<63:32> - CPU src2 

1 

fadd, fsub 

dest, srcl,src2 

FPU dest-FPU srcl op FPU src2 

4 

fmul 

dest, srcl, src2 

FPU dest—FPU srcl* FPU src2 

7 

fdiv 

dest, srcl, src2 

FPU dest-FPU srcl/FPU src2 

19 

fcmp 

srcl,src2 

FP_PSW < branch_bit > -(FPU srcl cond FPU src2) 

4 

fnegate 

dest, srcl 

FPU dest—FPU srcl with opposite sign 

4 

fabs 

dest, srcl 

FPU dest—FPU srcl with positive sign 

4 

fmov 

dest, srcl 

FPU dest-FPU srcl 

4 

int_to_extended 

dest, scrl 

FPU dest—(convert to extended) FPU srcl <63:32> 

4 

extended _ to _int 

dest, srcl 

FPU dest<63:32> —(convert to integer) FPU srcl 

4 

extended _ to _single 

dest, srcl 

FPU dest—(convert to single) FPU srcl 

4 

extended _ to _ double 
sync 

dest, srcl 

FPU dest — (convert to double) FPU srcl 

CPU waits until FPU is not busy 

4 

1 


double (64 bits), and extended-precision 
numbers (at least 79 bits) in a common 
87-bit format to reduce hardware com¬ 
plexity. SPUR enlarges the minimum 
extended-precision format in four ways. 

First, a three-bit tag identifies the type 
of a number. This tag reduces the time 
needed by a load instruction to convert 
numbers to extended-precision by allow¬ 
ing the load to handle exponents for all 
types of numbers in a uniform fashion. 
In addition, the hardware for compu¬ 
tational instructions can determine 
whether software assistance is necessary 


by examining the three-bit tag rather 
than the entire number. 

Second, SPUR expands the exponent 
by two bits so that trap handlers can ad¬ 
just denormalized operands. This en¬ 
ables SPUR to multiply and divide 
denormalized numbers using hardware 
designed for normalized operands. 

Third, two rounding bits are added so 
that SPUR can mimic rounding from an 
infinitely-precise result to a precision 
shorter than extended precision. This 
feature is necessary to correctly handle a 


denormalized number produced by an 
underflow exception. 

Fourth, one bit is used to hold the 
most significant fraction bit in explicit 
form. 

The floating-point coprocessor inter¬ 
face. The FPU is sufficiently fast that the 
performance of floating-point opera¬ 
tions is sensitive to the overhead asso¬ 
ciated with starting floating-point opera¬ 
tions and the overhead of transferring 
floating-point operands to and from the 
FPU. Consequently, 28 CPU pins are 
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used to implement a low-overhead inter¬ 
face between the CPU and the FPU. Un¬ 
fortunately, the close coupling of the two 
chips may make it difficult to use the 
SPUR FPU without the SPUR CPU. 

To reduce the overhead of starting 
floating-point operations, the FPU 
tracks all CPU instructions using 22 pins 
dedicated to carrying opcode, register 
specifiers, and other control information 
to the FPU (and possibly other coproces¬ 
sors). Some commercial floating-point 
coprocessors track instructions by moni¬ 
toring CPU instruction fetches to memo¬ 
ry (such as the Intel 8087). However, this 
will not work in SPUR because the CPU 
fetches most instructions from the on- 
chip instruction buffer. 

The SPUR floating-point interface 
reduces operand overhead in three ways. 
First, the floating-point registers reside 
on the FPU. Since all floating-point 
computation instructions operate with 
operands in these registers, intermediate 
results can be efficiently used. 

Second, floating-point load and store 
instructions transfer data directly be¬ 
tween the FPU and the cache. In con¬ 
trast, many commercially available inter¬ 
faces require floating-point data to be 
transferred through the CPU. The 
following sequence occurs when a float¬ 
ing-point load instruction is issued by the 
CPU: the FPU recognizes the floating¬ 
point load instruction and saves the 
destination register specifier; the CPU 
calculates the effective memory address 
and sends the address to the cache; the 
cache sends the data to both the FPU and 
the CPU; the FPU reads the data and 
loads it into the appropriate floating¬ 
point register; the CPU ignores the data, 
but recognizes that the load is complete. 

Third, the data path between the FPU 
and the memory system is 64 bits wide, in 
constrast to more commonly used 8-, 
16-, and 32-bit interfaces. This allows 
load and store instructions to move 
single and double-precision numbers 
with a single transfer and extended- 
precision numbers with two transfers. 
SPUR’s wide FPU interface reduces the 
probability that operand movement will 
limit floating-point throughput, which 
can easily occur for double-precision 
computations. 

The coprocessor interface also allows 
concurrent CPU and FPU operation. 
Subject to some software constraints, the 
CPU can continue executing general- 
purpose instructions, Lisp instructions, 
and floating-point loads and stores while 


the FPU is busy. Overlapping operand 
movement/index calculations with float¬ 
ing-point operations can halve the 
execution time of many inner loops of 
floating-point intensive programs. 30 
However, software must restrict the in¬ 
teraction between concurrently executed 
instructions by reordering instructions or 
by inserting sync instructions. For exam¬ 
ple, a sync instruction must be inserted 
between a floating-point operation and 
an instruction that stores the result of the 
operation in memory if the store could 
read the result register before it is 
written. 


Status 

The implementation of SPUR is in 
progress. As of September 1986 the 
custom components and processor board 
have been described at the register-trans¬ 
fer level with a variant of the ISP lan¬ 
guage and simulated with a software 
package called N.2. The layouts of the 
custom chips are near completion. They 
all use four-phase nonoverlapping clocks 
with a projected cycle time of 100 to 150 
nanoseconds. The processor board has 


been designed, simulated with N.2, and 
is nearly ready for physical implementa¬ 
tion. We expect to have working com¬ 
ponents by early 1987 and a working sys¬ 
tem later in the year. 


S PUR is a multiprocessor research 
vehicle, but we have not as yet 
been able to run multiprocessing 
experiments. Nevertheless, we have some 
preliminary results. 

First, selected architectural changes 
can significantly ease implementation 
and, at the same time, improve perfor¬ 
mance. For example, disallowing syno¬ 
nyms enabled us to build virtually-tagged 
caches without complex reverse-trans¬ 
lation mechanisms. Virtually-tagged 
caches improved performance by reduc¬ 
ing cache access time and permitting slow 
address translation. 

Second, in-cache address translation 
keeps PTEs consistent and offers perfor¬ 
mance comparable to a translation buf¬ 
fer at less cost. 

Third, cache consistency can be main¬ 
tained in hardware at reasonable cost 
and without any modifications to main 
memory boards. 
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Fourth, Lisp can be supported without 
a stack-based architecture and without a 
microcoded implementation. However, 
data-type tags or some other direct sup¬ 
port of Lisp’s dynamically-typed data 
are advantageous. 

Fifth, IEEE standard floating-point 
can be implemented without microcoded 
control if software handles the less com¬ 
mon cases. 

Sixth, floating-point coprocessor in¬ 
terfaces can be designed to significantly 
reduce operand-movement overhead by 
putting the floating-point registers on the 
floating-point coprocessor and loading 
these registers directly from a cache using 
a 64-bit data path. 

The goal of the first phase of the 
SPUR project is to design and implement 
several working prototypes. If the proto¬ 
types meet our expectations, we hope to 
find partners to help us transfer SPUR 
from academia to industry. □ 
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Electronic mail 
delivery for two cents 
(or less), user groups 
demanding (and 
getting) standards that 
meet their needs—this 
(and more) lies ahead 
for communications 
networks. 


T he pace of developments in com¬ 
puter-communications technol¬ 
ogy is impressive. All the more 
reason that, once in a while, we should 
stop and try to see where we have come 
from and where we might be going. The 
author is indebted to NCC 85 Session 
Chairman R.P. Case for the opportunity 
to do just that in the form of an invited 
talk at the July 1985 National Computer 
Conference. 

But before we begin, a word of caution: 
the author is by no means an expert in all 
the fields mentioned here. What follows, 
then, is a personal view of selected trends 
in computer communications. Among the 
topics covered are VLSI circuitry, satellite 
and fiber-optic transmission, integrated 
services digital networks (ISDNs), and 
personal computers—all as they relate to 
computer communications networks. A 
scenario of a future network applica¬ 
tion—one providing electronic mail and 
related service—shows how applications 
might develop and what the costs might be. 

Technology is moving! 

Semiconductors. The prime mover driv¬ 
ing communications at the current pace is 
the development of integrated circuits. 
Rarely, if ever, has a technology changed 
at such a rapid rate. Where the market is 
large enough, the cost of providing some 


Based on an invited talk at the National Computer 
Conference, Chicago, Illinois, July 17, 1985. 
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specific function has been dropping by 
close to a factor of one thousand over the 
course of a decade. 

Figure 1 shows these developments as 
seen by a large Japanese telecommunica¬ 
tions company, NTT. 1 The scale at the left 
shows the number of elements integrated 
on a single chip for bipolar logic (solid 
curve) and for MOS memory (dotted 
curve). The scale at the right shows the 
corresponding cost per element in US 
cents. The regular structure of VLSI 
memory chips makes their design some¬ 
what easier than that for logic chips, 
resulting in higher density and lower cost 
per element. Improvements of several 
orders of magnitude are evident over the 
twenty-year period depicted. The rapid 
evolution in computer communication is 
fueled by these improvements. 

Experts are divided as to whether the 
pace will continue after some 100 million 
elements per chip have been obtained 
around 1990. On the other hand much the 
same skepticism was expressed a few years 
ago, and without severely impeding prog¬ 
ress. What seems to be true is that we are 
now closer to the ultimate physical limita¬ 
tions of today’s materials and organiza¬ 
tion, so progress will become increasingly 
difficult. But we are long since at the point 
where it is economical and desirable to 
“cast” a great deal of communications 
function in silicon. Current semicon¬ 
ductor technology already provides ample 
horsepower to provide the terminal- 
access, interface, protocol-handling, and 
switching functions needed for a modern 
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Investment cost per circuit-year 



Figure 1. Progress in VLSI circuitry. 1 


Figure 2. Changes in the cost of a satellite channel. 2 


communication system. In most cases 
there is enough inexpensive processing 
power to provide almost any desired func¬ 
tion. Further, if the price is too high today, 
one can be sure that it will be lower 
tomorrow. 

It seems to me that the future will bring 
a new two-way communication network— 
for written messages—with nearly the 
same degree of pervasiveness as the 
telephone network. Examples of elec¬ 
tronic-mail networks exist today, such as 
the mail service of the ARPANet, CSNET, 
BITNET, various company-internal 
message networks, and MCI Mail, the lat¬ 
ter as an example commercial venture. But 
today these all appeal to rather special, 
highly skilled, and rather small user 
classes. 

Once there are enough subscribers, elec¬ 
tronic messaging will grow like wildfire. 
An example is the use of Teletel (the 
French videotex system) for electronic 
mail. At the end of 1985 there were some 
1.5 million users of the inexpensive Minitel 
terminal; three million are predicted for 
the end of 1986. Minitel was intended to 
replace the “yellow pages” printed phone 
directory, but its use for electronic message 
exchange is growing rapidly. 

Because it helps to have a framework 
for a discussion of the trends we are 
reviewing, let’s take a hypothetical mes¬ 
sage or document communication system 
as our conceptual framework. A number 
of components are necessary for such a 
system: high-capacity backbone-trans¬ 
mission trunks (connecting major switch¬ 
ing nodes), the switches themselves, local 
access to these facilities, and a ter¬ 
minal—the last as the user interface. We 
shall look at these in turn and, again, in the 


context of a network providing electronic 
message or document transmission. While 
there are other hypothetical networks we 
could select, this one will most likely have 
the largest user group. 

Backbone trunks. Satellite transmission 
links have long carried—and delivered 
on—the promise of reduced long-distance 
communication costs. Figure 2 shows the 
investment cost (in US dollars) per circuit 
per year for the Intelsat series of satellites. 2 

Progress in the case of satellites has been 
dramatic but not nearly as dramatic as that 
in the case of fiber-optic transmission. For 
the fiber-optic case, Figure 3 shows the 
product of the transmission rate (in 
gigabits per second) on fiber-optic trans¬ 
mission links, and the distance (in kilo¬ 
meters) over which this rate can be sus¬ 
tained without an intervening repeater. 3 
The curve shows experimental results 
from the laboratory. Using a technology 
deemed sufficiently reliable to be used on 
the ocean floor, the TAT-8 transatlantic 
link currently being installed has a figure 
of merit of about 10 (Gbit/s)(km); its cor¬ 
responding position is also shown in 
Figure 3. 

Satellite links will certainly play a key 
role in those cases where mobility or 
remoteness and very low traffic densities 
are factors or where (as in the case of TV) 
the broadcast capability of satellites is a 
commanding advantage. But for normal 
communication, even intercontinental, 
fiber-optics is bound to dominate. Com¬ 
mon carriers and Post, Telephone, and 
Telegraph Administrations (PTTs) in 
many countries have had fiber-optic trunk 
facilities in commercial operation for 
several years, and as we have just seen, in¬ 


tercontinental transmission facilities are 
now being installed. 

For data transmission, we are interested 
in digital transmission, and fiber-optic 
links lend themselves ideally to digital 
transmission. The process of trunk 
digitization is going on throughout the 
world. It is first taking place on traditional 
metallic cable trunks. But new trunks tend 
to be fiber-optic and digital from the start. 
Figure 4, based on Inoue and Tazaki, 4 
shows the dramatic increase in cost perfor¬ 
mance for fiber-optic compared with 
coaxial transmission at the trunk level. 
Shown is the relative cost per channel as a 
function of the route length in kilometers. 
From the point of view of trunk trans¬ 
mission, then, there will be abundant 
digital transmission at very advantageous 
costs. 

Switching. Digital transmission has an 
economic advantage over analog trans¬ 
mission at the trunk level. This advantage 
increases to the favor of digital trans¬ 
mission with the passage of time. The 
same is now true for digital switching. 
When a common carrier or PTT installs 
switching equipment, there are substantial 
cost benefits from reduced space and 
reduced maintenance expenditures when 
digital-switching equipment is installed. 
The use of digital switching combined with 
the increasingly available digital trunks 
opens the door to a carrier’s providing 
various services in an integrated fashion, 
that is, via a single switching and trans¬ 
mission network. This is the notion of 
ISDN (integrated services digital net¬ 
works). The transmission services might 
be transportation of text, data, and im- 
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Figure 5. Penetration of digital transmission and switching in 
Japan. 4 



ages, in addition to conventional speech 
traffic. 

All major suppliers of equipment to 
common carriers have a line of digital¬ 
switching equipment for which the tech¬ 
nology is now relatively stable. ISDN re¬ 
quires the addition of various functions 
and services to these basic digital switches. 
Digital switches with ISDN features cur¬ 
rently being marketed by the major tele¬ 
communication-equipment manufactur¬ 
ers are summarized in the March 1986 issue 
of IEEE Communications Magazine . 5 

How quickly will this digital system 
become available? The answer depends on 
the questions: For access loops or for 
trunks? For which country? Figures 5 and 
6 give the answer for Japan and for the 
Federal Republic of Germany, respective¬ 
ly, and were drawn after Inoue and 


Tazaki’s work 4 and after the FRG’s 
strategy report. 6 

Let’s look first at the situation for 
switching and transmission in the toll of¬ 
fices, that is, in the high traffic-density 
portion of the network. The uppermost 
curves in Figures 5 and 6 show the percent 
penetration of digital techniques at this 
level. Digital switching and transmission 
are coming very fast in this high-density 
portion of the network. 

Local access. One of the toughest prob¬ 
lems is the problem of transmission at 
reasonable cost over the “last few” 
kilometers—over the local loop from the 
switching exchange to the user. Here traf¬ 
fic density is typically low—particularly 
for the individual user. The access problem 
has been solved almost universally for the 


telephone user but at the cost of an enor¬ 
mous investment in copper and labor. It 
has been estimated that the portion of 
PTT plant investment in the local-access 
network (including a portion of local 
switching equipment) is some 35 to 40 
percent of the total investment. 7 The 
question now is how to duplicate this 
omnipresent access for digital data-based 
services such as electronic message 
handling. 

Here the concept of ISDN holds prom¬ 
ise. Figure 7 shows the most important 
access paths proposed for ISDN. The 
switches and high-speed trunks are shared 
in the high-traffic portion of the network 
by voice, data, facsimile, and other ser¬ 
vices; the same can be done over a digital 
local loop. Basic access is intended for the 
individual user. Rather than a 4-kHz 
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Figure 7. Local access via ISDN (integrated services digital networks). 


analog channel intended for voice, digital 
transmission can be used, and—over the 
same old twisted-pair local loop—two 
64-kilobit/second synchronous channels 
and one 16-kilobit/second asynchronous 
channel can be had. One 64-kilobit/sec- 
ond channel handily replaces the analog 
voice channel with another available for 
streams of high-speed data and another 
channel available for interactive lower- 
speed data. 

Again, this is done over the usual twisted 
pairs currently used for telephone traffic. 
There is no increase in cost for the copper, 
but what about the digital multiplexing 
equipment? Inoue and Tazaki 4 estimate 
the cost for the digital local loop to be 
somewhat less than double the current 
local-loop cost. As integrated circuit costs 
drop, the cost advantage for the data user 
could become substantial. 

For a cluster of business users, the ex¬ 
tended access is proposed. This is a 
primary rate channel of about 1.5 mega¬ 
bit/second. There are various possibilities 
for sharing this capacity among voice and 
data users. Within the business site, a local 
area network (LAN) would not only pro¬ 
vide communication between the various 
data users but also gather traffic for other 
destinations. A PABX would do the same 
for voice traffic. A gateway would then 
serve as the bridge between the LAN and 
PABX and the ISDN network connecting 


to other locations and remote communica¬ 
tion partners. 

Figure 8 summarizes the transmission 
speeds proposed for the time when there is 
digital transmission all the way to the end 
user. 8 

How soon will these facilities become 
available? The lower curves in Figures 5 
and 6 answer this question. Digital tech¬ 
niques will soon predominate in the high- 
density portion of the network because its 
use increases the common carriers’ return 
on investment. Digital access for busi¬ 
nesses will soon become available because 
businesses have a substantial need for such 
services and are an attractive market for 
the carriers. On the other hand, for the in¬ 
dividual user, there is little incentive for the 
carriers to install ISDN access equipment. 
When this occurs will depend on user de¬ 
mand. 

For the home and individual user- 
should the demand for sophisticated ap¬ 
plications such as color graphics become 
sufficiently large—the basic access could 
eventually be replaced by a digital in¬ 
tegrated fiber interface with much in¬ 
creased transmission capacity. This im¬ 
plies installation of a complete and entirely 
new local-access system. While this repre¬ 
sents an enormous investment, the success 
and penetration of the CATV industry (68 
percent of households in Belgium and 
Luxembourg and 49 percent in The 


Netherlands, to cite the two cases of highest 
penetration) do indicate feasibility. 9 

Terminals. At this point in the discus¬ 
sion, we have a digital network which 
theoretically could provide attractive, 
digital access to anyone. But this is not 
useful—for example for electronic mail— 
until there are a sufficient number of 
devices to give users functional access to 
the network. 

The personal computer—or the per¬ 
sonal workstation—is the most likely 
candidate. One view of the boom in these 
computers is shown in Figure 9, which is 
drawn from August 1984 estimates by 
EDP Industry Report . 10 

There is no good reason why a minimal 
personal computer, perfectly suitable as an 
electronic-mail terminal, should cost more 
than a TV set. If costs are higher, it will be 
because we are not satisfied with a minimal 
configuration and would like to have ex¬ 
tras, such as a color display, comfortable 
processing power, a reasonable capacity 
disk drive, and a printer. Taking a wide 
definition of the personal computer, it 
should eventually become as pervasive as 
the telephone or TV set. The simple 
French Minitel terminal mentioned above 
costs about $140. 

Summarizing, we have 

• personal computers as terminals (at 
the cost and potential proliferation of 
TV sets), 

• economically attractive access (via 
ISDN local loops and at an incremen¬ 
tal cost equal at most to today’s 
phone service), 

• digital techniques that should lower 
switching costs, and 

• fiber optics, which should reduce 
transmission costs. 


What will it cost? 

The question of cost is a tough one to 
answer. Let’s approach it by looking at a 
special case of what it costs today—know¬ 
ing that it should become substantially less 
expensive over the next decade, bearing in 
mind the cost trends just examined. 

The SITA network is a nonprofit 
association of most of the world’s airlines. 
It serves as a carrier for airline seat reserva¬ 
tion and other airline-related messages. 
Some figures for 1984, according to a 
SITA report, 11 are 

• 272 member airlines, over 1000 cities 
covered, and 198 telecommunica¬ 
tions centers worldwide; 
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Basic access 
2 B + D(16) 
where 

B = 64 kbit/s D(16) = 16 kbit/s 
Extended access 

(primary rate channels of total 1544 kbit/s) 
23 B + D(64) or 
4 HO 
where 

D(64) = 64 kbit/s HO = 384 kbit/s 


Figure 8. Access communication links for ISDN. 



• about 7,000,000,000 messages per 
year at an operating cost of $136 
million; and 

• cost per message—about two US 
cents. 

There are a number of factors to note. 
Much of the traffic in the SITA network 
consists of very short messages, say a line 
or two of text. Delivery is not guaranteed 
for all messages. SITA does not own its 
own trunks but leases them from the PTTs 
and common carriers. The figures do in¬ 
clude operating expense, including per¬ 
sonnel, but essentially no terminal costs. 

Now, if one compares the current cost 
of two US cents per message with the cost 
of sending a letter to a foreign country via 
airmail, takes into account the difference 
in delivery times, and considers that the 
two US cents per message should decrease 
with the introduction of new technologies, 
then the future for digital message trans¬ 
mission looks rather attractive. Perhaps it 
is worth adding that by some estimates 
more than 50 percent of first-class mail 
(bills and the like) is in any case generated 
by computer in digital form. 

The environment 

As far as the environment is concerned, 
this review would not be complete without 
some comments on deregulation and 
progress in standards. 

Deregulation. Strong forces are at work 
around the world to decrease the monop¬ 
oly position held by the world’s common 
carriers and to increase competition in the 
telecommunications industry. Certainly 
the most well-known example is the dives¬ 


titure of AT&T, which became effective in 
January 1984. The final results of this 
move will not be known for many years. 
What is clear is that competition in the US 
telecommunications industry—and in the 
US data processing industry—will sub¬ 
stantially increase as a result. 

The trend is not confined to the US. 
British Telecom is now a privately owned 
company and—no longer a monopoly— 
has competition in the information trans¬ 
mission business. 

In March 1985, a European Court of 
Justice Ruling, precipitated by a dispute 
regarding transatlantic telex service, laid 
down a position that clearly opposes PTT 
monopoly of all telecommunication ser¬ 
vices. The implication of this ruling is that 
developing value-added services should not 
be included within the PTTs’ monopoly. 

Also, since April 1985 in Japan, there 
has been some provision for competition 
in providing transmission as well as value- 
added communication services. 

Around the world there are many voices 
—one articulate example being the Euro¬ 
pean Community Ministers—pointing out 
the absolutely essential role that telecom¬ 
munications will play in future economic 
developments. Many countries have 
realized that excessive regulation of 
telecommunication will serve only to give 
the economic advantage to other coun¬ 
tries, both in terms of developing the 
telecommunications market itself and in 
terms of providing an attractive location 
for dynamic industries. 

Standards. We have talked principally 
about the development of hardware tech¬ 
nology and the efficient transportation of 
digital information. Clearly, more is 


needed, especially the software to provide 
services and the interface standards and 
protocols to make communication be¬ 
tween systems possible. 

For some years now, data-processing 
manufacturers have found it necessary to 
specify a system architecture and set of 
connecting protocols for their own family 
of equipment. Interconnection of dif¬ 
ferent manufacturers’ systems was, at 
best, difficult. This situation gave birth to 
the notion of OSI (open systems intercon¬ 
nection). The OSI principle maintains that 
if subsystem components all spoke the 
same language—that is, all followed the 
same protocols or rules of communica¬ 
tion—then within systems using these pro¬ 
tocols, it would be possible to connect any 
terminal via any network to any large com¬ 
puter. A collection of papers on OSI is 
contained in a special issue of the Pro¬ 
ceedings of the IEEE . 12 

During the last few years work on OSI 
has progressed rapidly and is now at the 
point where many manufacturers are com¬ 
mitted to developing software compatible 
with OSI. The idea is very attractive for 
users who wish to put computer communi¬ 
cations systems together with subsystems 
from many manufacturers, and for users 
who wish to communicate with correspon¬ 
dents outside their own system. Newly 
formed user groups are beginning to push 
hard for OSI (see, for example, the dis¬ 
cussion on MAP under the subhead “The 
rise of the user”). 

Local area networks provide data com¬ 
munication for many users clustered at a 
single site. In LANs one also has the inter¬ 
connection problem for many different 
kinds of equipment, and again standards 
have been developed for the information 
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transportation level. The IEEE 802 stan¬ 
dards for the token-bus, token-ring, and 
“carrier-sense-multiple-access with colli¬ 
sion detection” transmission media access 
methods are the most notable. 13 These 
have been designed to fit neatly into the 
OSI concept. 

It is also important, of course, that in¬ 
terfaces to common carriers throughout 
the world be uniform. For the new in¬ 
tegrated digital services, there are the 
ISDN standards 8 mentioned above. 

Finally, for the document-handling net¬ 
work we have taken here to represent the 
wave of the future, it is also mandatory to 
have standards that define messages and 
how they should be handled. International 
agreement has been attained on Recom¬ 
mendation X.400, 14 which deals with 
computer-based message-handling sys¬ 
tems. 

The recent progress in the standards 
area has been fast, and the standards 
themselves effective. Developments in the 
standards area will proceed continuously 
as experience with existing standards 
becomes available, new underlying 
technologies develop, and new services are 
deemed necessary. 

The standards themselves are new. But 
also new are the widespread agreement 
that communication between systems is 
vital, and the general willingness on the 
part of users, manufacturers, and carriers 
to contribute to international standards. 

It is instructive to follow one such devel¬ 
opment in a more detailed fashion. 


An example: 

The token-ring LAN 

The October 15, 1985, announcement 
by IBM of its token-ring local area net¬ 
work provides an example of several 
trends and issues discussed here. 

Beginning in 1979, a number of col¬ 
leagues at the Zurich Research Laboratory 
started to look at alternative approaches 
for a LAN. 15 They were drawn to the 
baseband token ring mainly because the 
one-way, point-to-point transmission in¬ 
herent in such an approach brings with it, 
when properly designed, a very high avail¬ 
ability. The ability to automatically locate 
and correct a fault using the ring topology 
further increases availability. 16 Other fac¬ 
tors favoring the token ring are the ex¬ 
cellent performance (partly a result of 
deterministic access), the ease of including 
priorities, and the capability of operating 


efficiently at higher speeds, even with 
fiber-optic links. 

The success of the ongoing research 
work, including a laboratory implementa¬ 
tion in Zurich, caught the attention of 
IBM telecommunication product devel¬ 
opers in Raleigh, North Carolina, in late 
1980. Convinced of the benefit of the 
token-ring approach, these researchers 
and developers made many contributions 
to standards bodies—first through the 
European Computer Manufacturers As¬ 
sociation, which resulted in the standard 
ECMA-89, 17 and then through the IEEE, 
which finally resulted in the ANSI/IEEE 
802.5 standard. 13 

Meanwhile, Texas Instruments and 
IBM agreed that TI would develop a com¬ 
pletely compatible set of chips implement¬ 
ing the token-ring protocol. TI announced 
its TMS380 five-chip set coincident with 
IBM’s announcement. Now, some com¬ 
ments on these developments. 

The whole process is very much in the 
OSI style. The published standard makes 
it possible for many manufacturers to 
build components that work together, 
giving network owners and users the de¬ 
sired flexibility to optimize their own tele¬ 
processing systems. The availability of the 
TI chip set goes even further, saving equip¬ 
ment manufacturers the engineering effort 
required to develop such an integrated cir¬ 
cuit and allowing them to produce com¬ 
patible products faster. In effect, the stan¬ 
dard has been “cast in silicon” and can be 
purchased as such. 

An enormous amount of function is 
contained in the token-ring standard, not 
only the basic communication protocol 
but also sophisticated reliability, avail¬ 
ability, and serviceability features. Ac¬ 
companying this increased availability is a 
lot of complexity. The TI protocol-handler 
chip (see Figure 10) has 195,000 elements, 
placing it in between the curves for logic 
and memory devices shown in Figure 1. If 
every teleprocessing equipment manufac¬ 
turer had to develop this and the remain¬ 
ing token-ring function, product cost 
would likely be prohibitive. 

The whole development was very inter¬ 
national in nature. This is evident in the 
ECMA, IEEE, and ISO standardization 
efforts, but even the IBM and TI efforts 
were themselves carried out by teams 
cooperating on an international basis. TI, 
in turn, has been working with a number 
of equipment manufacturers, including 
Finish and Swedish companies, to help 
them get an early start in developing their 
token-ring-compatible products. 


The point of this example is to illustrate 
several happenings that were simply im¬ 
possible a few years ago. We’ve seen 
widely based cooperation on a complex in¬ 
ternational standard that facilitates digital 
transmission between user workstations. 
Progress in VLSI has made both the distri¬ 
bution of intelligence evident in these 
workstations and the interface to these 
workstations economically attractive. 

Some shifts in emphasis 

Within the context of this brief review 
of the state of the art, what is really new? 
In many ways, not much—but only in the 
sense that we have become accustomed to 
an exponential rate of progress and even 
assume it will continue for at least the next 
few years. 

There are, however, several issues that 
have either grown in significance or are 


Complexity. Unfortunately, one of the 
phenomena that has accompanied much 
of the technological progress we have 
reviewed is a marked growth in complex¬ 
ity. For example, the exponential decrease 
in VLSI circuitry cost is accompanied by 
an exponential increase in complexity. 
Potentially, the amount of function pos¬ 
sible to implement as a VLSI circuit 
doubles every 1.3 years, but the complexi¬ 
ty and cost of the design effort to make 
this possible doubles every 2.3 years. 18 
These trends are shown in Figure 11. (Note 
that the TI TMS3 8020 token-ring protocol 
handler with its 195,000 elements comes 
close to the component-per-chip asymp¬ 
tote.) The reduction in cost depends on the 
difference between two exponential 
curves, and it is available only where the 
market for a VLSI circuit is so large that 
development cost is not a major factor. 

VLSI circuit design is just one example 
where we face—and must overcome—an 
exponential growth in complexity. There 
are many others. The functionality we ex¬ 
pect from our teleprocessing systems con¬ 
tinuously grows. The processors, and the 
number of processors on which these ap¬ 
plications are implemented, grow. The 
number of protocols and the complexity 
of these protocols grow. Deregulation, 
and the encouragement of freer compe¬ 
tition in the telecommunications industry, 
means a wider choice of services and 
(sometimes) reduced costs, but it nearly 
always entails an increase in complexity in 
dealing with many different subsystem 
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Figure 10. TI’s TMS380: a silicon standard. (Courtesy of Texas Instruments) 
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manufacturers and service suppliers. 
There is a growing need for complex sys¬ 
tem management tools in many areas of 
communications technology. 

Perhaps one of the toughest problems is 
controlling the complexity of concurrent 
operation of many processes or pro¬ 
cessors. Concurrency is needed to meet 
many of the functional demands we make 
on computer communication systems. 
Effective implementation and further 
development of the various OSI proto¬ 
cols—such as MAP and T/OP below— 
will benefit from tools for handling com¬ 
plexity in concurrent systems. 

In large systems, the demand for pro¬ 
cessing capability outruns the increase in 
speed of our technologies, and again we 
need concurrency, in the form of parallel 
processing, to be able to build the very 
large processing systems required in the 
near future. 

The human interface. A related prob¬ 
lem is that of the interface through which 
we access our computer-communication 


systems. There are few examples of a truly 
user-friendly interface. Even if there were 
more, one would likely have to master a 
different interface for each task. Some¬ 


Figure 11. 
Relative design 
complexity for 
VLSI circuits. 


how, the user has always had to adapt to 
the interface rather than vice versa. 

A 1985 survey by Business Week, which 
tried to identify the cause of the slump in 
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Figure 12. In the boiling caldron of tech¬ 
nological change. 


teleprocessing equipment sales, stated that 
31 percent of the respondents were busy 
“digesting” the equipment they had 
already purchased. 19 This is a comment 
on the current state of the human/com¬ 
puter interface and not a favorable one. 

The processing power to help overcome 
this problem is now available. And so are 
techniques such as expert systems that 


might be able to adapt to us rather than we 
to them. 

But the need for a good interface is not 
really new, and the growth of complexity 
has been with us for some time. Only the 
severity of these problems and the clarity 
with which they can now be perceived, 
given the experience of the last few years, 
are new. There is, however, a related 
trend—the rise of the user—that is new. 

The rise of the user. Throughout the 
history of telecommunications the user 
has been silent, with the possible exception 
of an occasional outburst caused by some 
particular exasperation. The user is now 
beginning to speak out. 

The OSI protocols mentioned above 
were not designed by users, per se, but 
have a strong user flavor. They were born 
of the exasperation of trying to intercon¬ 
nect the components of various telepro¬ 
cessing communications manufacturers. 

Probably the most publicized example 
of the user speaking out is MAP, a 
manufacturing automation protocol being 
proposed by the National Bureau of Stan¬ 
dards and General Motors. 20 MAP is 
based on one of the IEEE local-area- 
network protocols (the token bus) and the 


open-systems-interconnection protocols 
mentioned above. The idea is to have a 
language, that is, a set of protocols, which 
would be standard for the manufacturing 
automation industry. The users are in a 
position of being able to require MAP 
compatibility of telecommunications sup¬ 
pliers who want to sell equipment to group 
members. MAP carries quite a lot of 
clout—the US MAP Users’ Group has 
over two hundred industrial members, and 
a smaller group has formed in Europe. 

Similar, but not as far along, is T/OP, a 
technical/office protocol being advocated 
by the National Bureau of Standards and 
Boeing. 21 The aims are the same but in the 
engineering/office environment. 

The ability of protocol-conform prod¬ 
ucts from a large number of manufac¬ 
turers to communicate with one another 
was demonstrated at the National Com¬ 
puter Conference in 1984 and again at 
Autofact 1985. The MAP and T/OP pro¬ 
tocols formed the bases for these demon¬ 
strations. 22 

What is new here is that a large group of 
articulate and vocal users feels that they 
have enough experience from working with 
existing telecommunications equipment, 
and enough foresight for future needs, to 
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say what they want and to demand its 
delivery. This has not happened previously 
in the communications industry. 


O n the surface, we live in an age 
where exponential improvement 
is accepted, almost with a yawn, 
and expected to continue. Below the sur¬ 
face, there is a night-and-day competi¬ 
tive effort to sustain this rate of change. 
Some of the forces involved are shown in 
Figure 12. 

Technological progress leads directly to 
decreasing costs, which, in turn, make at¬ 
tractive the development of systems that 
supply more function. This opens new 
markets and increases demand so that 
economies of mass production can be used 
to further decrease cost. Deregulation 
with its encouragement of competition, 
thus reducing equipment and service costs 
and further increasing demand, adds new 
fuel to the cycle. The result is an incredible 
rate of progress—and complexity. The 
design of subsystems, the selection of sub¬ 
systems and services, and the interworking 
and maintenance of the overall system are 
all becoming increasingly complex. 

Yet the overall result is impressive. It 
promises a new, worldwide, two-way com¬ 
munication of all kinds of data: written 
messages, graphics, pictures—in fact, 
documents of all kinds. Starting in the of¬ 
fice and supported by LANs, its penetra¬ 
tion will ultimately approach that of the 
telephone or TV set. Basic communication 
could easily take place four orders of 
magnitude faster than with the present 
mail service and is already possible at one 
tenth its cost. The cost advantage will 
grow. 

Happily, for researchers, there are many 
problems yet to be solved—handling the 
complexity of large systems and software 
packages, improving system reliability, 
designing new protocols and standards, 
and finding better interfaces, to name a 
few—and future technological devel¬ 
opments will create additional problems. 
We are fortunate to be able to observe 
these changes as they take place and to be a 
part of the industry that is so deeply in¬ 
volved in them. □ 
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MACSYMA solves mathematical problems analytically 


Now you can do algebra, calculus, differential equations. 
Simplify, factor and expand equations. Compute with matrices. 
And more. Symbolically. 



and Numerically. 


(C6) FORTRAN(D5)$ 

Y = -(0.5518192»T»EXP(T)-T- 
1 / (0.5518192«EXP(T) -1) 


If you work with quantitative models in scientific or 
engineering disciplines, MACSYMA can increase your 
modelling power. MACSYMA combines symbolic and 
numeric computation. And enables you to accurately 
manipulate symbolic expressions in a fraction of the 
time required manually. 

Wide range of capabilities 

MACSYMA offers the widest range of capabilities 
for symbolic computations in applied mathematics of 
any commercially available program. For example: 

Algebra: MACSYMA can manipulate large expres¬ 
sions, expand, simplify and factor expressions, handle 
matrices and arrays and solve systems of equations. 

Calculus: MACSYMA can differentiate, perform 
definite and indefinite integration, 
take limits, expand functions in Taylor 
or Laurent series, solve differential 
equations and compute Laplace 
transforms. 

Symbolic-Numeric interface: 

MACSYMA can generate FORTRAN 
coding of expressions for numerical 
analysis or perform numerical analysis 
in the powerful MACSYMA™ language. 

Post-Processing: MACSYMA can 
plot in 2 or 3 dimensions and interface 
to standard mathematical text 
composers. 


Symbolically... 


For an information kit about all the 
ways MACSYMA can work for you, 
just call 

1-800-MACSYMA. 

In Mass., Alaska or Hawaii only 
call: (617) 577-7770. 


Broad base of applications 

Throughout the world thousands of scientists, engi¬ 
neers and mathematicians are using MACSYMA in 
such diverse applications as structural engineering, 
fluid mechanics, acoustics, CAD, electronic and VLSI 
circuit design, electromagnetic field problems, plasma 
physics, atomic scattering cross sections, control 
theory, maximum likelihood estimation, genetic studies 
and more. 

Compatible with many computer systems 

Current systems include: • Micro VAX II™, VMS™ 

• Symbolics 3600™ Series • SUN-2™ & SUN-3™ 

• VAX™, VMS™ & UNIX™ • Masscomp™ MC5500™ 
Other versions will be following soon. 


Or please write to us at: 

I"" Computer-Aided Math Group - Dept. M-CM-1 
| Symbolics, Inc. 

■ Eleven Cambridge Center 
1 Cambridge, MA 02142 
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I Company 

I Telephone Extension 

■ MACSYMA is available to colleges and universities at 
^ special rates. 


MACSYMA symbolics ™ 

The most comprehensive software approach Your next step in computing.™ 
to symbolic mathematical computations. 

























LisaLeaming 



Six people learned to 
use Lisa on their own. 
Their problems with 
the interface can 
teach designers how 
to make their own 
systems easier to 
learn. 
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IBM T. J. Watson Research Center 


P eople who do not already know 
how to use computing systems 
often have a difficult time learning 
how. Over the past six years, research at 
the Watson Research Center has focused 
on these learning problems and on finding 
solutions to them in better interfaces and 
training tools. 1 " 5 We have studied a variety 
of commercial systems and prototypes, 
and a variety of training approaches. Our 
goal has been to develop a thorough 
understanding of how new users interact 
with user interfaces—an understanding 
that can inform the design of future 
technology. 

Much of this work has focused on office 
workers with no prior experience with 
computers. We also focused on “tradi¬ 
tional” systems: systems with no on-line 
tutoring, with step-keys or contextual cur- 
soring, with character-box displays, or 
with no graphics (and therefore no text/ 
graphics integration). There are good 
reasons for focusing research in this way: 
Helping clerical users get started on tradi¬ 
tional systems is a pressing problem in the 
computer industry. 

But there are other user groups and 
other systems. Professionals, the people 
for whom the clerical users work, have 
more personal prerogative in determining 
which system they will use and what they 
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will do with it. The problems of getting 
started with a system are quite different 
for professionals. A system difficult to 
learn will not merely be an obstacle and an 
inconvenience; it may actually be dis¬ 
carded or returned to the vendor for a re¬ 
fund. 

User interfaces for professionals’ work¬ 
stations have broken rather sharply with 
what we referred to earlier as traditional 
user interface designs. The Apple Lisa, 
first introduced in January 1983 and 
discontinued in April 1985, is one of the 
most important examples of this trend. 
Lisa incorporated an on-line tutor 
(LisaGuide), a mouse-driven pointer, a 
bit-mapped display, and a fundamentally 
graphic interface (icons) for graphics ap¬ 
plications (charting, planning, and 
spreadsheets). 

The key ideas in Lisa received an en¬ 
thusiastic reception in the computer in¬ 
dustry. For example, in a review in 
Info World that named the Lisa as one of 
the top three personal computer/worksta¬ 
tions of 1983, Chin 6 specifically identified 
pointing and selection via the mouse, 
desktop windows and icons, and com¬ 
mands as outstanding features. She con¬ 
cluded that “Lisa has made giant steps in 
saving the user both time and frustration,” 
that it was truly “revolutionary.” These 
ideas also caused excitement in the 
research community under the rubric of 
“direct manipulation. ’ ’ 7 " 9 
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Table 1. Learner background and performance summary. 






LI 

L2 

L3 

L4 

L5 

L6 

Backgrounds 

Prior experience with computers (years) 

1 

6 

4 

4 

6 

3 

Number of different systems ever used 

2 

3 

3 

1 

5 

6 

Average current computer use (hrs/wk) 

9 

3 

7 

28 

15 

30 

Performance 

Use of LisaGuide (hrs) 

2.3 

1.1* 

3.1 

0 

1.2 

1.1 

Use of LisaProject (hrs) 

0 

2.3 

0 

0 

4.3 

.7 

Attempted LisaProject task 

N 

Y 

N 

N 

Y 

N 

‘Skipped three topics 


This was the context for our study. We 
wanted to research professionals’ work¬ 
stations and we wanted to study a less 
traditional type of interface, but one com¬ 
mercially available and with obvious im¬ 
pact. We thus decided to study profes¬ 
sionals learning to use Lisa. We focused on 
problems learners experienced because 
these indicated aspects of the design that 
needed improvement. We were not in¬ 
terested in Lisa per se, but in the class of 
systems of which Lisa was the best-known 
example. 

Overview of the study 

Our study of Lisa was exploratory, so 
we begin with disclaimers. We studied only 
six individuals, staff members at a 
research laboratory. These people may 
well have been atypical professionals. We 
did not perform any rigorous benchmark 
studies, since we did not care whether typ¬ 
ing a mailing label was faster on Lisa than 
on a competitive system. Rather, we tried 
to focus qualitatively on the design 
elements of the Lisa interface and training, 
and on their implications for learners. 

Our six learners responded to an on-line 
request for volunteers that we placed on 
our local computer network. We excluded 
volunteers who had substantial program¬ 
ming experience, but all of the six we ac¬ 
cepted had some experience with com¬ 
puters. A few had had some programming 
experience. We asked our learners to 
volunteer for two three-hour sessions, 
promising free coffee and the opportunity 
to learn to use a “new integrated commer¬ 
cial workstation.” Our group included a 
lawyer, a graphics designer working in 
patents, a publications librarian, a 


documentation designer, a researcher in 
automation design, and a research team 
manager. 

At the beginning of the first session we 
explained our ground rules: Learners were 
to work on their own; to imagine a real of¬ 
fice situation in which they were learning 
to use their own new personal workstation 
(one that nobody else had yet); and were to 
regard us as inert (albeit keenly interested) 
observers. We presented them with the 
system and two Lisa manuals (the owner’s 
guide and the LisaProject book) and 
asked them to learn to use the system, and 
in particular the LisaProject part of the 
system. We picked LisaProject because it 
seemed the most professional-oriented of 
the Lisa applications, as well as alleged by 
some to be ‘ ‘the best’ ’ Lisa application. 10 ’ 11 
We asked them to think aloud as they 
worked, and prompted them with “What 
are you thinking?” throughout the ses¬ 
sions as necessary to keep this self¬ 
disclosing monolog going. 

The two of us kept independent notes 
on what was said and done during the six 
hours. Later, we compared and cor¬ 
roborated our observations. The critical 
and typical episodes and incidents culled 
from our notes form the basis for our 
description of what it’s like to learn Lisa. 
Our plan was to have our participants 
spend roughly the first three-hour session 
covering basics and the second covering 
LisaProject and then performing a simple 
transfer-of-learning test (we asked them to 
use LisaProject to plan the schedule for 
nine phases in the construction of a three- 
bedroom house). Write-ups in the trade 
press and estimates in the Lisa documenta¬ 
tion assured us that this would be more 
than enough time. 


In Table 1 we have summarized the 
backgrounds of our six learners (LI-6) and 
the amount of time they apportioned to 
two major aspects of the system. 

On average, the five learners able to try 
the LisaGuide on-line tutorial spent over 
one and three quarters hours on it, or more 
than three times the half hour estimated by 
Apple and by the trade journals and news¬ 
letters (L4 made a single error that totally 
obstructed his progress). Moreover, two of 
the five were not able to use LisaGuide un¬ 
til their second session (that is, after three 
hours of previous experience with the sys¬ 
tem); and one of the five skipped three 
topic chapters of the tutorial. Only three 
of the six managed to try LisaProject, and 
one of them accomplished little. The other 
two spent an average of 3.3 hours learning 
the basics and accomplishing the project 
we had suggested. 

In sum, we found a lower level of suc¬ 
cess than we had been led to expect. 
Although our learners had had experience 
(with an average of four systems over an 
average of three years), they did not all 
finish the tasks we suggested. Indeed, L4 
and L6—who both spent more than half 
their work time using computers—failed 
to get to our LisaProject transfer-of- 
learning task. But these performance 
benchmarks tell us little in and of 
themselves. Hereafter we focus on prob¬ 
lems in the learning situation as we ob¬ 
served it. They help us understand why 
performance was poorer than we expected 
and how user interface design might 
benefit from addressing these problems. 


Getting started 

We saw many of the same problems over 
and over in prior work with other systems. 
For example, learners often fear that they 
will damage the system. As LI said, “Will 
I damage this if I turn it off with the disk 
in? There is a terror of destroying things, 
so I’m still a bit tentative.” This kind of 
fear was typical at the start of learning, but 
in the case quoted LI had already had four 
hours of experience with the system. 

Reading. Most of our learners did not 
want to read—as they demonstrated. 
Nonetheless, most entered the experiment 
announcing that they were the type of per¬ 
son who carefully read everything before 
trying to do anything. Two of them 
brought paper and pencil with which to 
take notes. For example, L4 apologetically 
informed us that we would have to watch 
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him read both the owner’s guide and the 
LisaProject book before he would use the 
system. Two minutes later he had turned 
on the Profile (the hard disk drive unit). 
L6 began the experiment by picking up the 
Lisa owner’s guide and announcing that 
his style was to first read everything 
thoroughly. Indeed, he actually read the 
manual for less than nine minutes before 
switching his attention to the system. He 
| next referred to the manual almost two 
hours later. 

L5 was the only participant successful at 
reading, but for an ironic reason. On her 
first day she inserted the LisaGuide disk in 
’ the wrong orientation and therefore 
! turned to the manual. She spent most of 
[ her first session reading and following 
printed exercises. Curiously, L5 was also 
| one of the two participants to get to the 
j LisaProject transfer test. But her success 
| was only relative. She had many problems 
\ coordinating the manual descriptions with 
j events on the display. For example, only 20 

j minutes into her first session she ex- 
j claimed, “I’m wondering as usual why it’s 
i not doing what the manual said it was 
; going to.” 

Learners had other specific problems 
using the manuals. L6 was afraid to turn 
the system off, thinking he might damage 
it. He checked the index of the Lisa 
owner’s guide for help and was directed to 
page 118. This turned out to be page 118 
(that is, capital 1-18). In his second session 
he wanted to review some concepts and 
could not find any index entries for “cur- 
! sor” or ‘ ‘pointer, ’ ’ nor any relevant entries 

( for “mouse” or “moving.” 

Misreading. Often when learners spent 
time and effort reading they became 
• snarled in confused interpretations and 
j cross-references. In his nine minutes of 
reading, L6 became troubled when he 
understood section B of the manual to 
I have referred him to section D, only to 
have section D then refer him to section B. 
f Later, he became tangled in a loop be¬ 
tween D-18 and D-20. One page seemed to 
him to be saying that to create a document 
or folder (directory) you must make a sta¬ 
tionery pad, and the other page seemed to 
be saying that to make a stationery pad 
you must create a document or folder. 

L4 read a reference to Figure 1 on page 
[ E-2 and associated the reference with an 

j unlabeled figure of a calculator icon that 
appeared on the same page. He never no¬ 
ticed that there was indeed a Figure 1 (la¬ 
beled as such) on the very next page (E-3). 
He became momentarily confused, and 


then irritated, by the fact that page A-4 of 
the owner’s guide suggested that the user 
read section A. As L2 put it, “If I were a 
machine, I’d be in an infinite loop.” 

L4 was also confused by references in 
the owner’s guide to “controller cards” 
and his discovery of quick-reference cards 
under the keyboard. This initial confusion 
went unresolved for almost 50 minutes. At 
that point he seemed to see the difference 
and became irritated: “What’s it going to 
help to know about controller cards? I’m 
not going to repair it; I want to use it! ” 

Skipping. When they did read, the 
learners tended to skip around in the 
manual. L4 simultaneously read from the 
owner’s guide and LisaProject, juggling 
the two in his lap, skipping between 
chapters and sections. L2 asked to see 
some of the other manuals, for example 
LisaList, and then skipped around in an 
even larger set of books. L5 also juggled 
manuals. At first she followed the owner’s 
guide, but failed to load the LisaGuide 
disk correctly. When the system booted, 
the desktop displayed. She recognized it 
from a figure in the LisaProject manual: 
“Oh! I have the wrong disk in. I thought I 
had LisaGuide in, but I have LisaProject 
in.” On the basis of this coincidence, she 
then skipped to the LisaProject manual 
for the remainder of the session. 

Turning the system on. Problems 
associated with reading the manual first 
were generally less troublesome than those 
associated with coordinating a reading of 
the manual with use of the system. L6 tried 
to follow an instruction that said “When 
you hear a click, hold down the Apple 
key.” He wondered whether he had heard 
a click (there were of course a variety of 
background noises emanating from the 
system as well as from adjacent rooms of 
our laboratory). He concluded that he had 
never heard a click. However, he went 
ahead and pressed the Apple key combina¬ 
tion anyway. By that time he had missed 
the cue and an alert box (error message) 
appeared: “Apple key combination not 
associated with available function.” This 
series of problems led him to conclude that 
he could not learn by doing, as he wished. 
He therefore decided to go through 
LisaGuide: “I was hoping to skip the 
LisaGuide, but I guess I need to go 
through it. I’m missing something.” 

Profile. L2 and L5 both turned on the 
system before starting the Profile (hard 
disk drive). L5 restarted from scratch 


when she saw her mistake, but L2 merely 
worried: “That might make a difference 
or it might not make a difference. ’ ’ He was 
presented with a diagnostic Start From 
dialog box (menu), but at that time was 
also reading in the book that the system 
took a long time to initialize, so he gave it 
more time. After several minutes, he 
began to consider other possibilities. He 
turned the system off, checked the orien¬ 
tation of a disk he wanted to load, and 
then tried to start up again. He read several 
troubleshooting sections of the owner’s 
guide and then tried to load his disk in the 
lower disk drive. By failing to turn the 
Profile on first, he had made the system 
code stored on the Profile hard disk 
unavailable. Finally, toward the end of a 
47-minute period, he tried to load another 
disk. Apparently by chance, he chose 
Office System 1, a backup of the system 
code. At that point, he was presented with 
several further dialog boxes (menus), 
which he did traverse successfully to ini¬ 
tialize the system. 

Response time. Many frustrations arose 
from the slow response time of the system. 
All of the five learners who managed to get 
the system initialized at all complained 
about response time. And this was more 
than inconvenience. In more than one case 
it led to serious trouble. L3 had tried to 
work on his own early in his second ses¬ 
sion, but had not succeeded. He decided to 
reload LisaGuide to refresh his memory, 
and in order to do this had to turn the sys¬ 
tem off. He did that correctly, but became 
impatient and pressed the on/off button 
before the system had finished its shut 
down. In doing this he hung the system up. 
Since he had experienced relatively long 
response times before in the shut-down 
situation, he just read on in the manual. 
After 18 minutes, he was sure something 
was wrong and asked us to intervene. 

L4 committed a fatal error in similar cir¬ 
cumstances. He was able to start the Pro¬ 
file, but became impatient during the long 
initialization period after pressing the 
on/off switch. This impatience led him to 
press the switch several more times before 
the system had booted, and to press an 
assortment of keyboard keys. The Start 
From dialog box appeared on the screen. 
Since he had not yet developed any skill in 
manipulating the mouse, he could not 
progress with the Start From dialog box. 
However, he did try the mouse button, 
clicking it several times. This caused the 
lower disk drive to be specified as the 
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r File/Print Edit Topics 


♦ Choose what to do next: • 

■ To stop LisaGuide: Hold down the Apple key to the left 

of the space bar while you press the period key. 
• To go on: Press Continue to begin the next topic, More 
Editing, or choose from the Topics menu. 

■ To leern about a specific kind of Lisa document, see 

"Getting Started" in the appropriate manual: 



Figure 1. Executing the alternatives in order caused an exit from the tutorial before the 
learner even saw the second or third alternatives. 


primary input device (instead of the Pro¬ 
file, so specified by default). 

At this point he was doomed as a new 
user. Each time he tried to start the system, 
he got error messages (alert boxes and 
dialog boxes). Since the LisaGuide disk 
did not contain its own system.code, he 
could not load it. Indeed, after commit¬ 
ting his error, L4 continued only one more 
hour. He then gave up in despair and asked 
to be excused from the experiment. 

Reviewers of Lisa 10 as well as the devel¬ 
opers 12 acknowledged the slow response 
time, but considered it a minor problem. 
From the perspectives of L3 and L4, it 
seems that little problems for experts often 
mean disaster for new users. 

On-line tutorial 

Typically, the learners tried to go it on 
their own—at first. In every case, how¬ 
ever, they made some obstructing error or 
became confused. For example, L6 was 
confused about the click he was supposed 
to hear while the system was booting. L4 
wondered why all the disks were stamped 
“Release 10” and what had happened to 1 
through 9. These uncertainties convinced 
them to try the on-line tutorial LisaGuide. 
As L6 put it, “I guess I need to go through 
it. I’m missing something.” 


Five of the six learners tried to load 
LisaGuide after having already booted the 
system. This caused an alert box (an error 
message display) to appear on the screen 
telling them to turn off the system and 
then turn it on again with the LisaGuide 
disk already loaded. All five were sur¬ 
prised that the system had to be turned off 
to load a new disk. L4, reading in the 
owner’s guide “...‘be sure the Lisa’s 
power is off’...” convinced himself that 
there was a typo. L5 and L2 had problems 
in loading the LisaGuide disk, which 
diverted them from using LisaGuide. 
Both, however, made a fresh start in their 
second sessions, and at that time managed 
to load and run LisaGuide. 

Rote learning with reinforcement. 

LisaGuide consisted of on-line lessons, 
each a series of exercises. Exercises were 
introduced, one after another, with no in¬ 
trinsic rationale. They were to be followed 
by rote. When told to move the mouse in 
circles, LI exclaimed, “Why are they tell¬ 
ing me to do this?” The exercise seemed 
pointless to him. 

Problems. Sometimes it happened that 
the method prescribed by LisaGuide was 
less efficient than one stumbled upon by 
the learner. While practicing replacement 
of text, several learners successfully and 


spontaneously employed the method of 
backspacing and retyping (instead of 
selecting a text range with the mouse and 
then typing to replace). They were dis¬ 
turbed to find the system advising them to 
be inefficient. L5 simply couldn’t believe 
that transactions with the Wastebasket 
could be as complicated as they seemed in 
the LisaGuide exercise (she was later 
relieved to learn that they could be 
simplified by shortcuts). 

Another problem: Exercise steps were 
written so that warnings occurred after the 
opportunity to make a mistake, and often 
information was provided after it was rele¬ 
vant. Throughout the early LisaGuide 
topics, LI was surprised that the cursor 
changed shape (from an arrow to a pair of 
opposed brackets) as it moved about and 
certain there was an important reason for 
this. He was quite annoyed that not until 
the end of the first topic of LisaGuide was 
he actually told that the cursor could 
change shape (he was still not told why). 
Subsequently, he was instructed to select a 
demo and only then warned that he need 
not have selected it if he had done well on 
the preceding exercise. He had already 
selected the demo at that point. 

A more costly example arose in the 
“Stopping LisaGuide” topic chapter, as in 
Figure 1. L1 executed the first step without 
reading ahead and accordingly ejected the 
LisaGuide disk. “Oh, I didn’t mean to do 
that. Now I’ll have to start all over.” He 
did in fact start over, going step by step 
through LisaGuide a second time. The 
tutorial did provide a Topics pull-down 
menu so that learners could accelerate the 
training if they wished (notice the field 
labelled “Topics” on the menu-bar at the 
top ofFigure 1). LI found the Topics pull¬ 
down menu and was able to use it, display¬ 
ing a selectable index of all the LisaGuide 
topics. However, he used it merely to con¬ 
firm his current state, selecting the topic he 
was already in (Topic 1). Instead of skip¬ 
ping back to the “Stopping LisaGuide” 
topic, he kept reinitiating Topic 1. Finally, 
“I’m in a loop here.” 

The printed material in the owner’s 
guide manual (accompanying LisaGuide) 
also presented information out of order 
with respect to the needs of the learner. As 
LI put it, “I’ve already loaded the 
disk —now they tell me not to touch the 
shiny plastic! ” 

L2 said it would have helped him coor¬ 
dinate sequences of instructions if the 
LisaGuide screens had been printed in the 
owner’s guide. The LisaProject manual 
also seemed to have order problems, 
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Figure 2. Executing Step 1 before reading Step 2 caused an exit from the tutorial without 
any hints about how to return. The “Do this...” heading attracted interest from learners 
before it was appropriate. 


although as we noted only two of the 
learners got to use it very much. In one ex¬ 
ample, L5 was following the LisaProject 
manual to draw a diagram from a figure in 
the manual. Upon turning the page she 
was shocked to find a step-by-step pro¬ 
cedure for drawing that diagram, out of 
order and too late to help her. 

More problems. Even without out-of- 
order instructions and warnings, learners 
still got lost within the exercises. For exam¬ 
ple, L2 named the same object twice in im¬ 
mediate succession. He was following the 
manual and simply overlapped himself. 
L5 reread instructions for opening a folder 
icon immediately after having completed 
them and became confused about whether 
she had in fact completed them. The in¬ 
structions, after all, were still there on the 
screen directing her to follow them. She 
tried to comply, by opening another folder 
icon. However, the system had disabled 
that choice in the File/Print menu (Figure 
4 below shows an example of this menu) 
because she had just opened an icon. 
Menu selection in Lisa was context depen¬ 
dent; menu choices inappropriate to the 
current context were dimmed and could 
not be selected. L5 knew something was 
wrong, because she had used the menu 
before to open folders. But she could not 
figure out what was wrong or what she 
could do about it. 

LI and L2 had trouble with a LisaGuide 
panel containing five steps, as in Figure 2. 
Just prior to the first step was a heading 
saying to read both instructions before 
doing anything. LI executed the first step 
before reading the second and was 
shocked when everything, including the 
LisaGuide window, was closed and set 
aside on the desktop. L2 ignored the first 
two steps entirely and focused on a second 
heading just prior to the third step, a 
heading that began with “Do this....” He 
then executed the next two steps. Because 
he had skipped the first two steps, he was 
unable to execute the last step. Save and 
Put Away was dimmed (disabled) in the 
File/Print menu, so he selected Set Aside 
Everything as a nearest approximation. 
But the “read both instructions before 
doing anything” actually referred to the 
two headings, not to the two steps im¬ 
mediately beneath it. 

Problems like the foregoing resemble 
those typical of learners following self- 
study manuals. They underscore the gen¬ 
erality and importance of such problems, 
and call into question the LisaGuide in¬ 


teractive training approach of placing self- 
study training on-line. 

Resistance to reinforcement and rote 
learning. The tutorial provided positive 
reinforcement messages to the user each 
time an exercise step was correctly com¬ 
pleted. L6 found these fatuous: “It’s silly 
to say excellent when they just told you 
that you did it wrong!” L2 felt insulted to 
be commended for following a relatively 
simple instruction. LI became snarled in 
an error loop of repeated Tear Off Sta¬ 
tionery operations, but when he did finish 
the step the system said “Excellent!” to 
which he replied, “The Hell it is!” 

The learners seemed to resist the rote 
learning whenever possible. For example, 
LI and L6 routinely executed the exercise 
summaries (which were intended to be 
read only). LI detested the demos (which 
allowed a learner to watch an exercise step 
performed before attempting to do it): “I 
can’t stand the demo because it’s set up for 
a 4th grade reading speed.” L3 expressed 
impatience with the tutorial, focusing on 
the summaries: “It might be nice to give 
you the opportunity to do more, without 
running through this trivial example.” On 
his second pass through LisaGuide, L3 
often jumped the gun on the exercise of 
particular skills. In many of these cases, 


LisaGuide obstructed his practice because 
he was out of sequence in the tutorial. LI 
resented alert box messages implying that 
although he had done something wrong, 
the system would let him go on anyway. In 
these cases, he preferred to go back and 
redo the exercise step—and thereby take 
control away from the tutorial. 

It seemed that the learners wanted to do 
something more concrete than follow a 
series of rote exercises. L2 balked at in¬ 
structions to read a passage but not to do 
anything: “I’m tempted to do it anyway 
and then see if I can get out.” Indeed, he 
moved the mouse during a demo when in¬ 
structed explicitly not to do so, then 
wondered why LisaGuide didn’t repri¬ 
mand him. 

Learners often tried to practice on their 
own within LisaGuide, like L6: “I just 
read how I could make a stationery pad 
from the menu, but I went to the menu and 
I couldn’t do it. They should let you make 
a note here.” An array of icons at the end 
of LisaGuide identified what was available 
in Lisa (refer to Figure 1), but one could 
not actually select them. After an hour of 
LisaGuide, LI complained, “I’m getting 
impatient. I want to do something, not 
learn how to do everything. ’ ’ After a hour 
and a half, he said, “I could have typed 
3000 words by now.” 
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File/Print Edit Topics 


♦ Notice how the File/Print menu works: 

1. Select the Exanple icon in the Semples window with a 
click, then see what the File/Print menu says. Don't 
choose from the menu. 


3. Be sure the Clipboard window is active, then choose 
Set Aside "Clipboard" from the File/Print menu. 
(Doesn't say Set Aside "Clipboard"? Redo step 2.) 
Watch the Clipboard window close and return to the 
place marked on the desktop by its white icon shadow. 



1=1 Empty Foioers 


Figure 3. Overly terse error du 
create ad hoc interpretations. 


sis and recovery help, as in Step 3, invited learners to 


Error shielding. In many places 
LisaGuide permitted small user errors, 
correcting them automatically as the user 
passed on to the next exercise. Sometimes 
it informed the user that such and such a 
response was being altered to whatever. At 
other times, it provided no feedback or 
incomplete feedback. The response was 
altered surreptitiously, as it were. A typical 
example occurred when participants used 
names they had created instead of the 
names suggested by LisaGuide. At the end 
of the exercise, LisaGuide put in the name 
it had suggested and went on, briefly put¬ 
ting up a panel that explained that the 
user’s name had been replaced by the 
name the system had originally suggested. 

Over-shielding. After such an error and 
error correction, the system offered 
several choices: Practice, Demo, Back, 
and Continue. L6 initially found these too 
telegraphic: “Practice what? Demo of 
what? Back to where?” He picked Con¬ 
tinue, the only choice he had not 
eliminated. Still he complained, “It 
doesn’t tell you to go to Continue at the 
end of an exercise.” Later, he tried the 
Back option to find out why a name he had 
typed in had been replaced. However, 
LisaGuide did not take him back to the ex¬ 
planation about names, but rather back to 
the prior exercise step (the point at which 
he was originally asked to type in a name). 


Indeed, the only way he could truly go 
back to the point he wished to go to was to 
recommit the same naming error. L5, who 
made very few mistakes in LisaGuide, 
wondered why the system couldn’t just go 
on and spare her the trouble of selecting 
Continue after each step. 

LI tried to rename an object, but 
misspecified it (using the mouse). He 
typed in the new name without conse¬ 
quence (no beep, no error message, no 
feedback at all). When the system asked if 
he was sure that he understood (intended 
as tactful and positive reinforcement), he 
laughed, but went on anyway. LisaGuide 
put in the name he had failed to put in, and 
several minutes later he was quite sur¬ 
prised to find it there. 

In a converse example, LI (as well as L2 
and L5) typed in several fields of a practice 
memo that he had not been told to type in. 
LisaGuide deleted his extra material at the 
end of the exercise step. Surprised to find 
this material gone, he retyped all of it. (Of 
course, LisaGuide again removed it on the 
next exercise step.) 

In another incident, LI selected Set 
Aside instead of Save and Put Away in the 
File/Print menu. At the end of the exercise 
step, LisaGuide informed him of this error 
and gave him the option of going back and 
redoing the step. He did, and correctly 
used Save and Put Away, but ignored the 
rest of the step—the operations he had 


already correctly practiced on his first time 
through. Having finished the step the sec¬ 
ond time, he was again informed that he 
had incorrectly performed the step. 

L2 encountered a similar problem select¬ 
ing multiple icons. He correctly completed 
the LisaGuide exercise step on this, but 
began to wonder why one would ever want 
to select multiple icons in the first place. 
He backed up to the relevant step and 
reread the panel. Satisfied, he moved on 
again, but at that point LisaGuide put up 
an alert box because he had not actually 
done the exercise step. He felt compelled 
to work through everything again. Accord¬ 
ingly, he backed up and selected a new 
group of icons (for variety). But of course 
he had again failed to do just what the ex¬ 
ercise step said, and LisaGuide treated his 
new effort as an error, too. 

LisaGuide’s error shielding also pre¬ 
vented learners from practicing individual 
skills they had mastered. L2, having just 
learned about scroll arrows, tried to 
operate them on the LisaGuide window. 
However, scrolling operations do not 
work in the LisaGuide window, preventing 
this sort of practice. This caused frustra¬ 
tion and confusion since it made the scroll¬ 
ing operations appear to work unreliably. 

Under-shielding. The foregoing ex¬ 
amples suggest that error shielding creates 
some problems for new users, but we also 
saw cases where correcting errors only at 
the ends of exercise steps provided too 
little shielding. In the second chapter of 
LisaGuide, LI spontaneously decided to 
practice icon selection. In the course of 
this he positioned an icon so that it par¬ 
tially occluded another icon. He was then 
unable to select the occluded icon, which 
was required for the next exercise step. He 
tried to correct this in several ways, in¬ 
cluding performing the exercise step on 
another icon. But all of his attempts failed. 
When he gave up and tried to go on, 
LisaGuide automatically corrected the 
error, but in a sense it was too late. 

L2 resized a window so that it was 
wholly within (on top of) the LisaGuide 
window. Later, when he activated the 
LisaGuide window, this other window 
became wholly buried under the LisaGuide 
window (the currently active window 
moves to the “top” of the display area). 
Hence his other window became inaccess¬ 
ible for further use. 

Likewise, L3 was practicing moving 
icons around the desktop and accidentally 
released a folder icon while it was superim¬ 
posed over another folder icon: “I lost 
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Figure 4. The Lisa desktop. The Profile icon has been selected (it is highlighted in the 
lower right of the desktop) and the File/Print menu has been pulled down. 


Supplies!” By releasing the icon over a 
folder, he had placed that data object into 
the folder, hence it became invisible on the 
desktop. 

Error diagnosis and recovery. The feed¬ 
back LisaGuide provided for learner er¬ 
rors was in many cases too general to help 
the learner adequately understand the 
problem. For example, most learners 
made errors coordinating the selection of 
icons from the display. LisaGuide de¬ 
livered identical error feedback for nam¬ 
ing the correctly selected icon with the 
“wrong” name as it did for selecting the 
wrong icon but naming it with the “cor¬ 
rect” name (the name LisaGuide sug¬ 
gested). In the second case, the error feed¬ 
back was all but uninterpretable. 

When directed to put a folder into the 
Wastebasket and then to recover it, LI put 
it first into the Wastebasket, then into a 
disk window, and then back into the 
Wastebasket. The alert box said “You put 
it into the diskette instead of onto the 
desktop”—an inadequate description of 
what actually transpired. 

As in the case of the selection/naming 
errors, LisaGuide provided some support 
for error diagnosis and recovery, but not 
enough. However, in both cases the system 
purported to be providing complete sup¬ 
port, which led to confusion for learners. 

In dealing with error recovery, 
LisaGuide often employed somewhat 
“cute” checkpoint questions, such as 
“Doesn’t say Set Aside ‘Clipboard’? Redo 
Step 2” (seeFigure3). This message meant 
that if the File/Print pull-down menu did 
not list as a choice “Set Aside ‘Clipboard’” 
the user should redo Step 2 in the exercise. 
L3 read and reread this message. Even 
though he had successfully completed the 
exercise, he backed up a step and began 
repeating part of his work. At that point 
he did make a mistake. In response, he 
backed up another step. At that point he 
chanced to notice that “Set Aside ‘Clip¬ 
board’” was listed as a choice in the 
File/Print menu. From this sequence of 
events he drew this conclusion: “Maybe 
they’re telling me that it really doesn’t 
mean set aside Clipboard.” Unfor¬ 
tunately, this conclusion was entirely 
wrong. 

Summary. The tutorial was far less suc¬ 
cessful than we had either hoped or ex¬ 
pected. The learners did not like it, did not 
cooperate with its rote learning approach, 
and worst of all did not seem to gain much. 
Most of them spent most of their time run¬ 


ning and rerunning LisaGuide, but when 
they went to apply what they had learned 
they could not. Minutes after finishing 
LisaGuide, LI became puzzled by the 
icons at the bottom of the screen: “What’s 
all this junk at the bottom?” After two 
further passes through LisaGuide, he 
complained that he hadn’t learned about 
any of the pull-down menu headings on 
the menu bar (he had in fact used some of 
them). He summed up: “I am tremen¬ 
dously frustrated. I’ve done a lot of work 
and I can’t do a damn thing.” 

L3, who had finished LisaGuide 16 
minutes earlier, tried to create his oym 
document and simply could not get 
started: ‘ ‘I have completely forgotten how 
to open, enter, to create a document!” He 
could only open and close icons and exper¬ 
iment with choices in the pull-down menus. 
After several cycles, as if in desperation he 
typed a burst of characters in an open win¬ 
dow. Fortunately, the window was a blank 
document, so he succeeded. 

Ironically, the only two learners who 
succeeded in making serious progress with 
LisaProject (the overall goal we gave the 
learners) were L2 and L5, who initially in¬ 
serted the LisaGuide disk incorrectly and 
therefore could not use it at all during their 
first sessions. These incidents give a 
somewhat ironic twist to Merkin’s claim 10 
that “Learning how to use Lisa by trial 
and error is so much fun that to learn it 


methodically by going through the tuto¬ 
rials provided for each software package 
seems insipid.” 

The desktop 

The Lisa interface was one of the first to 
systematically and pervasively exploit a 
coherent interface metaphor: the desktop 
(see Figure 4). The user was encouraged to 
think of the display as a desktop contain¬ 
ing objects that could be physically 
manipulated. But this interface posed 
problems for the new user, some of them 
terminological complexities peripheral to 
the desktop interface metaphor. 

For example, L4 read the description of 
the Calculator and became confused by its 
technicalities. He did not know the terms 
“reverse Polish calculator’’ or “four func¬ 
tion calculator,” nor did LI or L6. L3 was 
confused by the term “highlighted.” 
After several minutes of puzzlement, he 
exclaimed, “Oh! When it turns from white 
to black it’s highlighted.” 

Other problem terms were “profile” 
(which refers to the system’s hard disk), 
“preferences” (which refers to the default 
display settings), and “tools” (which 
refers to the Lisa applications, like 
LisaProject, and icon functions, like the 
Clock and the Calculator). 

The term ‘ ‘tool’ ’ serves as a good exam¬ 
ple of an ancillary metaphor too general to 
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imply anything useful. L5 became snarled 
in confusion between untitled icons and ap¬ 
plication “tools”: “They tell you to use 
the tool to tear off a piece of stationery, 
but when you go to do it you’re not allowed 
to in this screen.” The confusing message 
about using the tool suggested to her that 
the tool was indeed like a stationery pad, 
or even like a piece of stationery. She 
looped through a sequence of selections, 
failed renamings, openings, closings, etc., 
for over half an hour before giving up. The 
“tool” here was the application function 
(LisaWrite text-editing operations), not 
the application objects to which the func¬ 
tion applied (pads, stationery). 

Unfortunately, such conceptual prob¬ 
lems arose even more frequently for terms 
more central to the interface, such as 
“icon” and “clicking.” L4 noted that 
“icons” are religious figures, and in fact 
never made the connection between that 
term and the system’s little interface 
pictorials. He confused “mouse” with 
“icon” when reading the instruction 
“click twice on the calculator icon,” con¬ 
cluding that the thing he was to click twice 
(namely, the mouse and its button) was the 
calculator icon. 

L2, L4, and L6 had trouble with the 
term ‘ ‘clicking. ” As L6 put it, ‘ ‘What does 
‘clicking in the little picture of a diskette’ 
mean?” Not until the end of the second 
chapter of LisaGuide did he find out: 
“Now they tell me....” L2 pursued several 
references to the “clock” in the owner’s 
guide when he first encountered the term 
“click.” Later, he encountered a dialog 
box instruction to “check” boxes and 
wondered whether “click” could be the 
same as ‘ ‘check ’ ’ (it was in this case, which 
reinforced his confusion). 


The metaphor. Other troublesome con¬ 
cepts and labels exposed problems with the 
desktop metaphor itself. The first class of 
these involved problems people had un¬ 
derstanding the desktop meaning for 
terms like ‘ ‘clipboard, ’ ’ ‘ ‘stationery pad, ’ ’ 
“typing,” “tear off stationery,” and 
“folders.” For example, LI read the refer¬ 
ences to the “Samples diskette” in 
LisaGuide (which referred to the diskette 
icon on the desktop but not to any real 
disk) and looked for a floppy disk. 

The manipulation of stationery pads 
seemed to the learners to be mere over¬ 
head. To get a piece of memo paper or a 
folder in Lisa they had to select a template 
icon (called a stationery pad), “tear off” a 
copy using the File/Print menu, and only 


then open the new icon for work (assigning 
a name to the new icon was optional). LI 
complained, “I write my memos before 
tearing them off. If they’re going to use 
analogies they ought to do them right!” 
LI particularly objected to the metaphor 
as applied to folders: ‘ ‘Tear Off Stationery 
has no relation to empty folders—it’s 
being cutesy beyond understanding.” L6 
complained about the necessity for selec¬ 
tion, tearing off stationery, reselection, 
renaming, and opening just to create space 
for data: “Why must I tear off just to get 
at something?” 

The metaphor distinction between sta¬ 
tionery paper and stationery pads often 
caused confusion. For example, after L3 
selected and opened an icon he was unable 
to edit it because it turned out to be a sta¬ 
tionery pad. After tearing off a copy of a 
stationery pad and opening the new icon, 
L3 was still thwarted in trying to type 
anything because he had been working 
with a folder stationery pad. To him, sta¬ 
tionery pad suggested something you 
could write on, but in Lisa “stationery 
pad” was a technical term. 

L5 also created a plethora of accidental 
icons as she tried to sort out “duplicate,” 
“tear off,” and “open.” Later, when she 
cleaned up her desktop (by moving these 
icons to the Wastebasket) she discarded 
her (renamed) LisaProject Paper icon. 
The system allowed her to do this even 
though it obstructed her further progress 
with LisaProject. 

LI and L6 both tangled aspects of the 
Tear Off Stationery problem with a prob¬ 
lem interpreting the Clipboard metaphor, 
when they tried to Tear Off Stationery 
from the Clipboard to type something. LI 
also tried to type directly onto the Clip¬ 
board and then Edit it, evoking alert box 
error messages both times. Note that from 
the standpoint of the desktop metaphor, 
all of these errors and confusions were 
perfectly reasonable. In fact, the only pur¬ 
pose of the Clipboard was to temporarily 
store things during cutting and pasting; it 
was not really a general scratchpad (as its 
name implies). L6 wondered why there 
was a Clipboard on the desktop at all. 

Even the window concept, critical to the 
interface, did not derive from the desktop 
metaphor. Neither did the scroll bar or 
elevator concepts (icons that appeared in a 
Lisa window and were used to control 
scrolling). These misfits, gaps, and 
misleading cases weakened the efficacy of 
the metaphor. 13 Indeed, since they were 
never addressed as concepts in the inter¬ 
face or the documentation, they created 


additional burdens of metaphor com¬ 
prehension and metaphor confusion. 

LI balked at the LisaGuide description 
“...closes a window and places it on the 
desktop.” He said this meant nothing to 
him, but conjectured that it might mean 
that something was deleted (a wrong 
guess). L2 learned about scroll bars, but 
could not keep the concepts together. 
Within minutes of learning it, he could not 
remember what a scroll bar was. (LI had a 
similar problem.) 

Prior experience with computing sys¬ 
tems. A second class of metaphor prob¬ 
lems involved confusing Lisa concepts 
with other computing concepts, and ex¬ 
pectations derived from other systems. 
LI, for example, balked at “folders,” 
preferring the more abstract term “files,” 
which he had had prior experience with in 
his current system. “If they’d just tell me 
that we’re using analogies and later will 
switch to computer language, I’d feel better.” 

L2’s puzzlement with the term “click” 
was exacerbated early on by the fact that 
he limited his consideration to the 
keyboard keys. L4 became convinced that 
he needed a blank disk to store his work 
on, and that that single problem was the 
key to his difficulties. Unfortunately, his 
difficulties had nothing to do with this ex¬ 
pectation, presumably grounded in his 
prior experience with other microcom¬ 
puter systems. 

Other notable concepts in this class were 
“enter” and “edit” and keyboard func¬ 
tion keys. L3, while following a LisaGuide 
exercise, was disturbed to find that having 
typed in a string he was not then directed 
to press the Enter key (something he ex¬ 
pected based on prior experience with 
other systems). Reasoning that he should 
go ahead anyway, he became disturbed to 
find that pressing Enter had no apparent 
consequence. Somewhat ironically, the 
Lisa designers specifically included an 
Enter key to be compatible with other 
product designs. 12 

L1, L2, and L3 were all surprised to find 
that the Edit menu contains only opera¬ 
tions for cutting, pasting, and copying. 
The systems they had used before em¬ 
ployed the term “edit” to refer to all 
operations on documents, including docu¬ 
ment creation. LI, while using LisaGuide, 
complained that he needed a keyboard 
function key for Continue, the operation 
that advanced users through the series of 
exercise steps (and which in Lisa was a 
soft-key, a field on the screen that was 
selected using the mouse). 
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Figure 5. Icon ghosts. The LisaProject Examples icon and the Ad Schedule icon were 
nonfunctional placeholders for currently open windows. They could not be selected or 
manipulated. 


We even saw evidence that prior knowl¬ 
edge of basic keyboard layout interfered 
with learning about Lisa. For example, L3 
tried to stop LisaGuide by pressing the 
Shift key in conjunction with the Period 
after being instructed that the correct com¬ 
bination was Apple plus Period. L5 also 
had trouble with the Apple plus Period 
combination. She executed it correctly, 
but it failed to work because she had never 
actually loaded LisaGuide. At that point, 
she found another (irrelevant) Period key 
on the numeric keypad to use in the com¬ 
bination. 

Conceptual distinctions. Several Lisa 
concepts seemed to cause problems chiefly 
because they were confused with other 
Lisa concepts, quite aside from being 
jargon or obscurely metaphoric. We have 
already mentioned the confusion between 
applications (tools) and their parts. We 
also observed confusion about “view,” 
“select,” and “open”; “set aside” and 
“save and put away”; “menu” and 
“menu bar”; “icon,” “icon ghost,” and 
“window”; and “duplicate” and “tear 
off.” 

L3 became confused between ‘ ‘opening’ ’ 
and “selecting.” While working with the 
Clipboard open he went to the File/Print 
menu: “ I ’ m surprised that I can only select 
Set Aside, and that I can’t open it.” L3, 
while using LisaGuide, was directed to 
open an icon. He ignored the direction 
because he couldn’t find the choice Open 
in the menu bar (the choice was in fact 
listed in the File/Print menu, available 
from the menu bar). L6, trying LisaCalc, 
concluded that he needed to have the 
Calculator open in order to use it, but 
couldn’t figure out how to use them 
together. 

L6 selected an icon and went to the View 
menu to “view” the window, confusing 
the View menu with the File/Print menu. 
This error quickly became established and 
he made it repeatedly during both ses¬ 
sions. He would reorganize his icons 
chronologically, alphabetically, and pic- 
torially, but could not open anything. A 
variant of the error that developed late in 
his second session was selecting the Edit 
pull-down menu for functions like Open 
and Save and Put Away. 

L6 and L3 confused icons with the win¬ 
dows they stood for. L6 picked up a 
window and moved it to the File/Print 
menu to save it (instead of selecting the ob¬ 
ject and then pulling down the File/Print 
menu to operate on it). L3 picked up a 
window and moved it over the Waste¬ 


basket icon to throw it away. Even later in 
the second session, after more than four 
and a half hours of experience, L3 tried to 
put away an object by picking up the win¬ 
dow and superimposing it on another 
window. 

L2 confused icons with icon ghosts. 
(When icons were opened into windows, 
ghost images of them remained as non¬ 
functional place holders. See Figure 5.) 
While his Wastebasket was open, he tried 
to discard a document by dragging its icon 
to the icon ghost of the Wastebasket. 
When he released the document icon over 
the Wastebasket, it returned to the 
desktop. L3 also had this problem in try¬ 
ing to place document icons into icon 
ghosts of open folders. 

The distinction between Set Aside and 
Save and Put Away troubled our learners. 
LI was disturbed by Save and Put Away 
because he felt that the two conjoined 
operations were distinct and should be 
listed separately. L3 experimented to dif¬ 
ferentiate Set Aside from Save and Put 
Away. In the course of this, he tried to 
Save and Put Away the Clipboard. The 
Clipboard, however, could not be saved 
and put away. 

L6 decided to Save and Put Away a disk 
(which could only be Set Aside). He re¬ 


jected the Set Aside option and switched 
objects instead, finally saving and putting 
away a folder. 

L5 developed a baroque procedure for 
saving. She would first select Set Aside 
from the File/Print menu, then drag the 
icons from the desktop into the Profile 
window to save them (which is precisely 
what the single operation Save and Put 
Away did). 

We also saw some confusion about 
pointless nondistinctions in the system’s 
jargon. L6 became confused about the 
difference between “top of the desktop” 
and “active window” when there was no 
difference. 

To summarize, the desktop metaphor 
was far more complicated than it might at 
first appear. It is quite unclear whether it 
facilitated learning more than it puzzled 
and misled our learners. Even aside from 
the metaphor, the many fine distinctions in 
the Lisa commands and concepts caused 
numerous learning difficulties. Surpris¬ 
ingly, in view of the various learner prob¬ 
lems we observed with respect to the desk¬ 
top metaphor and other Lisa concepts, the 
trade press assessment was entirely 
positive: “The Lisa’s software com¬ 
mands, such as Store, Save, Put Away and 
Print, are straightforward.” 6 
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Basic user interaction 

Selection and pointing. The most basic 
interaction channel, particularly for the 
novice user, was mouse positioning and 
clicking for selection. This format ob¬ 
viously differs from more traditional 
menu selection and cursor movement with 
step-keys. The learners we studied seemed 
to have problems both in the basics of 
pointing using the mouse with simple 
clicking and in more advanced operations 
involving multiple coordinated mouse 
clicks. 

The mouse. While the mouse device had 
useful properties, it also posed problems. 
LI and L6 felt strongly that the mouse was 
for 15-year-olds, but not forthem. LI said 
that the mouse click was not tactually ob¬ 
vious enough. LI and L3 had trouble 
coordinating cursor position, especially 
when positioning the cursor to type in text 
(or to use Space or Backspace). 

Interestingly, this problem persisted 
throughout both sessions. Even after five 
and one half hours LI had trouble posi¬ 
tioning the cursor to delete text with the 
Backspace key. L2 pulled down the 
File/Print menu to open a selected icon, 
but as he pressed the mouse button and 
checked in the manual to be sure he was 
right, his finger slipped and he duplicated 
the icon instead. 

The converse problem, in which a per¬ 
son did not click in a field but selected it 
anyway, also occurred. While printing, L3 
attempted to redundantly specify the print 
quantity parameter. Since that field had 
already been selected, his mouse click was 
taken by the system as a selection of 
another field, one horizontally across 
from the print quantity field on the 
display, namely the Cancel field. Thus, in 
trying to redundantly specify the print 
quantity, he actually canceled his print 
job. He failed to notice any of this, but did 
notice that the printer did not produce any 
output. (L3 had a similar experience using 
the scroll elevators which, once on, con¬ 
tinued to cause scrolling even if the cursor 
was moved out of the elevator “shaft.”) 

Double-clicking (a shortcut in which an 
icon was both selected and opened) also in¬ 
vited clicking errors. L5 routinely clicked 
too slowly and hence selected but could 
Olnot open her icons. L2 also had this prob¬ 
lem, but later reasoned out how double¬ 
clicking ought to work. Unfortunately, he 
chose to test his hypothesis on a stationery 
pad icon. Double-clicking a stationery pad 
selected and then tore off an untitled piece 


of stationery, instead of selecting and open¬ 
ing. L2 was puzzled by the result of this ex¬ 
periment. 

Pressing versus clicking. The system 
distinguished between pressing and 
holding down the mouse button and click¬ 
ing (quickly holding down and then releas¬ 
ing the mouse button). The wording of 
system prompts always carefully respected 
this distinction, but our learners never¬ 
theless found it troublesome. After one 
and one half hours of experience with the 
Lisa, LI wondered, “What’s the dif¬ 
ference between clicking and pressing?” 
One difference was that pressing the 
mouse button on an icon allowed one to 
drag the icon around the desktop. L5 
pressed the mouse button as the second 
half of a double click and hence ended up 
reluctantly dragging a highlighted icon 
around the screen. 

A variety of selection errors occurred 
throughout the sessions. Each of the five 
learners who managed to get started had 
trouble with the basic select and open pro¬ 
cedure: click an icon to select it, then move 
the mouse to the File/Print menu and 
press (not click) the mouse button. 
Learners initially clicked the mouse in or 
near the File/Print pull-down menu, in¬ 
stead of merely pressing it. L2 explained 
that he wanted to, but could not, get the 
pull-down menu to stay down. 

These unnecessary clicks had the side ef¬ 
fect of deselecting the originally selected 
icon and accordingly of dimming (that is, 
disabling) menu choices associated with 
the icon. Hence, a learner who clicked 
instead of pressing in the course of using 
the File/Print menu to open an icon might 
well have found the Open choice in the 
File/Print menu disabled. 

This type of error occurred with a vari¬ 
ety of operations. In trying to close a win¬ 
dow, LI and L3 miscoordinated the mouse 
click for selection and hence failed to find 
the desired Save and Put Away choice in 
the File/Print menu. Both pointlessly 
clicked on the dimmed Save and Put Away 
choice anyway, which had no effect 
(similar to clicking on an icon ghost), but 
which elicited no feedback from the sys¬ 
tem, either. L3 attempted to select an icon 
and then move it into the Wastebasket. He 
slipped with the mouse button and de¬ 
selected the icon before dragging it to the 
Wastebasket. In the end, the Wastebasket 
icon was selected (and highlighted) and the 
original icon was exactly where it had been 
when he started. 

L6 made the same selection error trying 


to replace text, and succeeded only in 
replacing a portion of the text he had tried 
to replace. LI made an error in trying to 
rename an icon, then slipped and selected 
the wrong icon, putting the new name 
onto another icon entirely. L5 pressed in¬ 
stead of clicking on the Wastebasket when 
she wished to open that icon. She ended up 
rather unhappily dragging the icon up to 
the File/Print menu. 

Understanding selection. Some of the 
learners had trouble with the cause and ef¬ 
fect relations of selection through pointing 
and clicking. L6 expected that selecting a 
window would cause it to get larger as well 
as to come to the top of the desktop stack 
(possibly he confused “icon” with “win¬ 
dow”). He tried to select an already- 
selected window, found that nothing hap¬ 
pened, and concluded that selection as 
described did not work. 

L5 deselected a window and commented, 
“I got rid of part of the menu.” From the 
system’s standpoint, she had brought a 
different window to the top of the display 
stack and thereby occluded part of the 
original window. Her description did not 
include any notion of window stack or 
selection in its cause/effect analysis. 

LI developed the belief that there were 
two methods for selection. One was to 
select an icon and then go to the File/Print 
menu to Open. The second was to drag an 
icon up to the File/Print menu. Actually, 
the second method never worked, but a 
significant element of it was useful, name¬ 
ly, holding down the mouse button. Li’s 
most typical selection error was to fail to 
select initially or to deselect along the way 
to the File/Print menu. Hence, if he fo¬ 
cused on the goal of dragging (and its 
requirement that the mouse button be 
pressed and held), he was more likely to 
execute the first selection method suc¬ 
cessfully—albeit with an incomplete 
understanding of what he was doing right. 
Nevertheless, a side effect of his procedure 
was that he often ended up with icons col¬ 
lected in the upper lefthand corner of the 
display. 

There were a variety of where and when 
problems with selection. LI clicked in the 
wrong window when two windows sat on 
top of each other. L3 and L5 clicked on 
icon ghosts, which activated the window 
within which the ghost icons were located, 
but had no effect on the ghosts. Moreover, 
when L3 and L5 subsequently went to the 
File/Print menu, choices pertaining to the 
ghost icon were not available. Halfway 
through the second session, L3 was sur- 
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prised to find that a window could be ac¬ 
tivated by a click anywhere within it. He 
had remembered that activating a window 
required clicking in the field containing the 
window’s name. L6 accidentally selected 
all his icons simultaneously and then could 
not stop moving them in unison each time 
he moved the mouse. 

People sometimes became slightly 
superstitious about selection. The menu 
bar changed, as did the choices in the 
menus themselves, as the system environ¬ 
ment changed. The View menu, for exam¬ 
ple, initially listed on the menu bar, disap- 
[ peared when application windows were 

opened and was replaced by menus spe¬ 
cific to the applications. L3, having just 
opened a LisaWrite window, concluded 
that he had lost View by sloppy operation 
of the mouse. He was very careful for a 
time after that, but View did not reappear. 

Throughput. Managing the Lisa desk¬ 
top was quite different from interacting 
with more traditional interface designs. 
For example, the user did not have to 
specify names for data objects; the system 
would leave them untitled. L6 was 
puzzled, but also pleased, that he could 
have several objects named “untitled,” 
perhaps based on his experience with other 
systems. However, LI named two things 
“First File,” his own folder and the Pro¬ 
file, and later became confused about 
what the name referred to. 

Typing. Typing in Lisa drew upon a 
paper page and typewriter metaphor. The 
display was black-on-white, and at times 
the metaphor was really quite compelling. 
However, it broke down somewhat during 
editing (insertion and replacement of text) 
and when moving and copying text. 

For example, L3 was troubled by the 
fact that Lisa typed in insert mode, placing 
new characters between existent charac¬ 
ters and adjusting prior material to the 
right. He initially assumed that the Space 
Bar would delete by typing blanks over his 
prior work; however, he found that it in¬ 
serted blank spaces and merely pushed his 
prior work aside. L3 seemed to want a 
typeover capability so much that he 
invented one. He combined the replace 
mode, in which one selected a piece of text 
with the mouse and then typed in replace¬ 
ment text, and the insertion mode, in 
which one positioned the cursor and then 
typed. He stated that he could position the 
cursor with the mouse and type over the 
existing text (which was wrong). 

There were often invisible effects in 



Figure 6. Checking the Clipboard for intermediate results of a cut/copy operation 
resulted in placing a selected piece of text into the name field of the Clipboard. 


Lisa’s metaphoric typing page. LI turned 
on Center and then had trouble getting the 
signature line in his letter where he wanted 
it. The system continued to center every¬ 
thing he typed. L6 selected a portion of 
text adjusted to flush right. The text 
became highlighted, but so did the right¬ 
most spaces between lines of text (which 
concealed invisible formatting characters). 

Cut, copy, and paste. Operations that 
deleted, or temporarily hid, data were 
always dangerous for our learners. LI in¬ 
advertently selected his entire document 
and then cut, which deleted all his work up 
to that point (actually, it was temporarily 
saved in the Clipboard, but LI did not 
know this). He retyped the entire text, but 
then selected Revert to Previous Version. 
He thought that this would restore his 
original text, but in fact it reverted to the 
version immediately following the cut, 
again deleting all of his work. 

The potential costliness of Cut was ex¬ 
acerbated by an unintuitiveness in the 
ordering of Cut and Paste, at least for LI. 
He consistently selected the Paste opera¬ 
tion before cutting the text he wanted to 
paste and before specifying the location. 
Perhaps he felt timid after his earlier ex¬ 
perience with Cut, but the error persisted 
throughout the six hours. In one case, it 
led him to paste leftover remnants of 
another document into his current work. 


Toward the end, when he finally got Paste 
to work, he became snarled in a paste 
loop, cutting and pasting over and over. 

L6 also had trouble coordinating selec¬ 
tion of text to be cut/copied. Worried 
about this, he tried to check the Clipboard 
for the temporary results. After specifying 
the text to be cut/copied, he selected the 
Clipboard (actually he selected the name- 
field of the Clipboard icon) to check for 
results. When he then selected Paste, his 
text was copied not into the Clipboard but 
onto it, as a new name. A reconstructed 
example is shown in Figure 6. L6 had ac¬ 
cidentally discovered how to rename 
icons. After this, although the File/Print 
menu continued to refer to the Clipboard 
by its original name (Clipboard), it re¬ 
mained permanently relabeled for this 
learner, who ignored it. 

LI wondered why Cut and Paste was 
not integrated into a single Move, which 
would have eliminated the risk of losing 
data with Cut: “It’s funny that with this 
mouse capability, you can’t just select and 
move text instead of this cut and paste.” 

The Wastebasket. Several of the 
learners became quite absorbed with the 
Wastebasket. L6 duplicated an empty 
folder in the Wastebasket, which unfor¬ 
tunately led him to believe that certain 
types of work could be carried on there. 
Later, he threw away the LisaList Paper 
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and the Calculator icons, although he 
commented immediately, “It shouldn’t let 
you do this!” 

The same problem occurred with L5, 
who lost her LisaProject Paper to the 
Wastebasket. In the midst of working with 
the application she had decided to clean up 
some practice documents. Earlier she had 
inadvertently renamed the LisaProject 
Paper icon, hence it was accidentally 
thrown away as a practice document. 

L2, while trying to close the Calculator 
window, wondered whether the Waste¬ 
basket might play some role in putting 
things away. Fortunately (in a sense), he 
was unable to operate the Wastebasket. 
He tested the use of the Wastebasket by 
placing an icon directly into the open 
Wastebasket window. This would have 
worked, but he forgot to release the mouse 
button and hence dragged the icon back 
out of the window. He concluded that the 
Wastebasket had to be closed on the 
desktop in order to function. 

Undo. Lisa provided an Undo opera¬ 
tion, but it tended not to be available when 
needed or wanted. For example, L3 in ex¬ 
perimenting with the Clipboard made two 
successive cuts from a document. He then 
selected Undo and restored the first cut. 
He selected Undo again, but merely ob¬ 
tained the system message that the 
previous operation could not be undone. 
The irony here was that even if the Undo 
operation had worked it would not have 
done what L3 wanted. Lisa’s Undo did not 
stack prior system states, it only retained 
the prior state at any given point. Hence, it 
merely alternated the immediately preced¬ 
ing state with the current state. 

A typical system response to an Undo 
request appears in Figure 7. 

Oddly, reviewers found the Undo more 
impressive than our learners did: “With 
this command, even the most uncertain 
users will not hesitate to act in a way they 
think is appropriate.” 14 

Printing. Our learners experienced a 
variety of problems getting output from 
Lisa. L6 requested a print when the printer 
was turned off. A rather complicated alert 
box referred to technical difficulties and 
advised the user to check cables, ribbons, 
and paper; to read through section G of 
the owner’s guide; and to report Difficulty 
Number 3056. Ironically, the extensive 
alert box did not say to check the on/off 
switch. Moreover, when the participant 
ultimately turned the printer on, he had to 
reissue his print commands to get output. 


Other problems involved ancillary print 
commands. When L2 requested his first 
print job, a LisaProject plan, he had to 
respond to three dialog boxes in succession 
to get a print. He wondered, “Why are 
they giving me such a hard time?” 

In other cases, learners found print 
commands irresistible. The only menu 
choice available in every context from the 
File/Print menu was Monitor the Printer. 
Learners tended to select this choice early 
on, when they had no print jobs to mon¬ 
itor. When LI went to print, he noticed 
that Format for Printing appeared prior to 
Print in the File/Print menu. He did not 
need to format for printing, but selected it 
anyway. This error had little consequence, 
merely delaying him. (In a similar case, 
when trying to Tear Off Stationery, he 
selected Duplicate because it too came first 
in the menu; this latter error had substan¬ 
tial consequences.) 

LisaProject. Our original intention was 
to study LisaProject, perhaps the most in¬ 
novative and original of the Lisa applica¬ 
tions. Our learners seemed utterly unim¬ 
pressed with LisaProject. Said L6, “I’ve 
never in my whole life had to do a chart 
like this or wanted to. I can’t imagine a 
situation in which I would.” Later, “It’s 
just flowcharts.” 

This perception of limited usefulness 
might be ascribable to a lack of prior 
knowledge about PERT charts, upon 
which LisaProject was based, on the part 
of our learners. We did not ask them about 
this. 

Aside from the issue of perceived use¬ 
fulness, there were a variety of problems 
much in the spirit of selection problems we 
saw in other contexts. For example, L2 
had trouble selecting the title field on his 
LisaProject Paper. L6 opened the 
LisaProject master and was told to Tear 
Off Stationery from LisaProject Paper, 
but the LisaProject master window had 
covered up the Profile icons when it 
opened, including LisaProject Paper. 

L5 tried to connect a series of task 
boxes, but ended up selecting pieces of text 
within the boxes while positioning the 
pointer. When she did succeed in connec¬ 
ting boxes, the click establishing each join 
occasioned a brief flash on the display. 
The first time, L5 worried that she had lost 
the box. 

L5 connected the task boxes in the 
wrong order and hence produced a project 
plan diagram that did not match the exam¬ 
ple in the manual. To explain this to 
herself, she pointed out what was in fact 


an irrelevant typo as the cause of the 
mismatch. Later, having corrected the 
typo, she examined the project diagram 
and found it still mismatched: “Wrong. I 
must have put another typo in.” 

L6 had trouble moving the Start circle 
because he clicked within the circle (gener¬ 
alizing from other selections) rather than 
on its boundary, as he should have. L6 
began typing in the LisaProject window, 
but was immediately interrupted by an 
alert box with the message, “Before you 
type make a selection. ’ ’ This puzzled him, 
but eventually he selected the Start circle 
and resumed typing not a label, but text. 
The circle grew until he had typed 50 char¬ 
acters, at which point he was again inter¬ 
rupted with an alert box. By that point, 
however, the Start circle had covered up 
most of the window. 

L5, as noted earlier, threw away her 
LisaProject Paper icon. She tried to use 
LisaDraw Paper instead and rapidly came 
to the conclusion that she could not 
substitute. She diagnosed her problem, 
however, and tested it experimentally by 
throwing away the LisaDraw Paper icon. 
(For her second session, we restored the 
LisaProject Paper, based on our expecta¬ 
tion that she would not be able to recover 
from this error.) 

A variety of problems pertained to 
LisaProject in particular. Both of the 
learners who managed to work with Lisa¬ 
Project had difficulties setting dates for 
project plans. They seemed to have little 
intuitive understanding of what the ap¬ 
plication was doing. L5 tried to set dates 
for a single task box. When she finally 
reached the Set Schedule Dates dialog 
box, she made the total duration of the 
project two weeks, the time allotted for the 
first task. L2 wondered, ‘ ‘What does early 
start or late start mean? At this point I’m 
just following the instructions without 
thinking.” When L2 tried to set dates for 
his house building project, he became 
snarled in confusion among “calendar 
range,” “current date,” and “start date.” 

Similar problems arose in the area of 
resource allocation. L2 created two sepa¬ 
rate task boxes, in parallel, for a two-man 
task—a legal but baroque solution. L5 
placed a two-man resource on two lines of 
a single task box, which was more efficient 
but incorrect. LisaProject interpreted this 
as two separate resources (and since L5 
placed the resource amount parameter 
next to only one name, her other resource 
was syntactically incorrect as well). L2 
joined three parallel task boxes to two par¬ 
allel task boxes with six lines (LisaProject 
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Figure 7. A typical system response to an Undo request. 


expected a milestone circle at junctures 
like this). 

Finally, both L2 and L5 found the ap¬ 
plication too inflexible. Both noticed that 
the user could not update the project plan 
from the resource task representations. L2 
also wished to be able to specify variable 
amounts of resources for task boxes. 


Remarks 

In our description of professionals learn¬ 
ing to use Lisa, we have tried to stay as 
close to pure reporting as possible. Our 
goal, to that extent, has been to catalog the 
problems as we observed them. In this 
final section, we take up a slightly higher 
focus, and remark more generally on the 
design process, on the nature of learning, 
and on the use of interface metaphors. 

Designing for usability is not simple. 

Our starting point is a paradox: Lisa was 
deliberately designed to be very easy to 
learn. The claim was made that people 
could be working productively after 30 
minutes. 14 And this was not merely 
wishful thinking. Research and devel¬ 
opment work specifically targeted this 
goal. The desktop metaphor was devel¬ 
oped to help make new users “comfort¬ 
able.” Nevertheless, the 30-minute 
estimate was off by as much as an order of 
magnitude for our learners. And the 
desktop metaphor caused specific and 
tangling problems for new users. How can 
this be? 

The designers of Lisa, like an increasing 
number of system designers, reported that 
they developed the user interface design in 
parallel with other aspects of the 
project. 12 They ran user tests during the 
development process. Do we conclude 
that their tests were misdirected? Inade¬ 
quate? No. The only reasonable view 
seems that in spite of pertinent and timely 
research and development work, the Lisa 
interface was formidably difficult, even 
for professionals with some computer 
experience. 

This really should not be surprising. 
Lisa was a powerful workstation with 
many diverse capabilities and a detailed in¬ 
terface. Details really matter, because they 
can tangle into perplexing morasses of 
confusion for users. The Lisa interface 
contained many novel elements, so that 
any amount of testing would from some 
standpoint have been inadequate. Our 
view is simply that the job of innovating 
new interface concepts is an open-ended 


one. We are confident that the Lisa design 
process improved the product’s interface, 
as we are that the interface can be im¬ 
proved further. The question is not “How 
could Lisa have been so bad?” but “How 
can we learn from the Lisa experience and 
goon?” 

We do feel that the intensely en¬ 
thusiastic reception of Lisa by the small- 
systems community reflected attitudes 
that ought to be examined. Every review 
we read proclaimed that Lisa was easy to 
learn, but none provided any empirical 
basis for such a claim. Perhaps reviews 
ought not to be as casual as they some¬ 
times are today. In an otherwise insightful 
review, Williams 14 referred to the follow¬ 
ing alert box message as “incredibly 
clear”: “The tasks and milestones cannot 
be moved off the drawing. Try enlarging 
your drawing size with the Page Layout 
menu.” True, this is far from the worst 
error message ever written (and it was not 
the worst in Lisa either). But for the user 
who is not sure what a “milestone” is 
(they were never labelled as such), or a 
“task,” this message is quite useless. And 
as our descriptions show, such trouble¬ 
some situations did occur for new users. 

Focus on critical user tasks—like getting 
started. Our study suggests some major 
problem areas in the Lisa design. We 
would like to underscore three of these. 


First, problems associated with initializ¬ 
ing the system were potentially disastrous 
for new users. Indeed, one of our six 
learners fully realized this potential and 
another escaped narrowly. 

Second, the training available for Lisa 
was inadequate. The manuals were fat and 
redundant, and learners had trouble using 
them. The on-line tutorial seemed ineffi¬ 
cient and ineffective; it was frustrating and 
even insulting for learners. 

Third, the system’s interface—mouse 
pointing and selection, the graphic desk¬ 
top, etc.—was clearly no design panacea. 
Selection was difficult to coordinate and 
desktop icons difficult to understand. 
Some of our learners found the entire in¬ 
terface concept just plain silly. Moreover, 
the consistency and integration of the in¬ 
terface often disappeared in all its dif¬ 
ficulties. For example, we understand 
from Don Hatfield that the actions of 
resizing a window and of resizing a Lisa- 
Project task box were designed to be 
thought of as a single sort of operation 
that applied across applications. Neither 
we nor any of our learners noticed this 
consistency. 

Systems can be designed to avoid the 
serious getting-started problems we 
observed. One way to organize the design 
process to achieve this is to analyze the 
critical user subskills that are prerequisites 
for accomplishing typical user tasks. 15 In 


November 1986 


47 








Lisa, examples of these critical user sub¬ 
skills would include switching between 
and integrating different applications. The 
design of Lisa does suggest that attention 
was in fact paid to empirically testing and 
refining the interface for such user sub¬ 
skills, but that less attention was paid to 
the subskill prerequisites for getting 
started. 

Design training materials for realistic 
active learning. Getting the system started, 
as we have seen, was only the first of many 
challenges for Lisa learners. One key 
problem with Lisa was the same one we 
have documented in prior research: 
Learners do not do what designers want 
them to; instead they tend to get actively 
involved and to think and plan and solve 
problems. 16 This thread permeates the 
description we have given of professionals 
learning to use Lisa, particularly for our 
description of the use of the LisaGuide 
tutorial. 

Many times these active learning strate¬ 
gies led to successful outcomes. For exam¬ 
ple, L2 had trouble understanding the 
Wastebasket and conceived of several ex¬ 
periments in which he tried to throw away 
objects, then opened the Wastebasket to 
check on his success. He noticed that pull¬ 
ing a menu down from the menu bar tem¬ 
porarily halted the printer and tested this 
several times to be sure he was drawing the 
right conclusion. He worried about the 
automatic dimming of the screen, so he 
tested its connection to mouse movement 
by experimenting. In each case, causes and 
effects were systematically correlated as he 
actively created his understanding of the 
system. The fact that Lisa made many sys¬ 
tem functions visible allowed this active 
learning approach to succeed. 

There are of course numerous pitfalls to 
active learning. For example, one can 
rummage around in a domain but not get 
to the important content. LI and L6 had 
interactions with the Calculator that ex¬ 
emplify this problem. They were both at¬ 
tracted to it because it seemed familiar and 
perhaps simpler than LisaProject. How¬ 
ever, LI became absorbed in the fact that 
some of the buttons didn’t look as much 
like buttons as did others (such as the MC 
button). L6 used the Calculator but failed 
to try any memory functions, comment¬ 
ing, “So that’s all the Calculator can do.” 
In both cases, the exploratory learning had 
a less than inspiring outcome: Neither 
individual mastered the Calculator. 

When learners do notice some feature, 
they seek an explanation for it. They can 


become frustrated and/or confused if no 
explanation is obvious, as L5 indicated in 
her reaction to an inscription she found in 
the border of a document window: “4692 
blocks free out of 9690.” As she said, “It 
makes me feel that I did something wrong.” 
Worse, perhaps, they may concoct an in¬ 
appropriate explanation for what they 
believe they have observed. L2 got an alert 
box message: “Before you type make a 
selection.” The alert box contained a but¬ 
ton labelled Cancel. L2 reasoned that this 
was the selection referred to, and he 
clicked the Cancel. ‘ ‘I guess they were try¬ 
ing to save me from an error I was about to 
make; by typing Cancel I averted it.” 
Cancel was not the selection referred to in 
the alert box, and his Cancel action did 
nothing more than dismiss the alert box. 

Learners had understandable difficulty 
in trying to reason out jargon terms (like 
tool and profile) and to resolve fine 
distinctions in terminology (Save and Put 
Away versus Set Aside), in objects (icon 
ghost versus icon versus window), and in 
actions (press versus click versus double 
click). Experimenting with these distinc¬ 
tions can be costly and time consuming, 
especially when an incorrect alternative 
(clicking on an icon ghost) evokes no sys¬ 
tem response or when Undo is unavailable 
for escape from the consequences of errors. 

These troubles must be taken in context, 
of course; the training approach of Lisa 
was clearly at or beyond the general state- 
of-the-art. Nevertheless, alternatives 
should be considered. LisaGuide was in 
many ways an awkward compromise be¬ 
tween training books and interactive train¬ 
ing. The tutorial relied too much on 
reading from the screen and carrying out 
seemingly pointless practice exercises for 
demeaningly cute verbal rewards. Oddly, 
from this perspective, LisaGuide and the 
owner’s guide (the actual training manual) 
were not coordinated. They were two in¬ 
dependent, but quite redundant, training 
approaches. 

Lisa’s error shielding (given the poten¬ 
tially distracting and frustrating conse¬ 
quences of errors) was probably a good 
idea. But one could argue that the straight 
tutorial approach of LisaGuide was too 
rigid a vehicle for error-shielded training. 
One small error can spoil an entire effort. 
Conversely, when LisaGuide did not shield 
errors, it often provided too little feedback 
for successful error diagnosis and recovery. 

We have recently studied a “training 
wheels” approach, in which error shield¬ 
ing was employed in a scaled down, but 
functional, system. In a training wheels 


system, new users can take the initiative 
and learn by doing (which they cannot do 
with LisaGuide) with the benefit of error 
shielding. 2 

Design interface metaphors for mis¬ 
matches as well as for matches. A concrete 
metaphor, such as the desktop, can make a 
system interface easier to learn (or even 
“comfortable”). At Yorktown, some of 
our work has been directed at understand¬ 
ing how interface metaphors can impact 
learning. 13 ’ 17 ’ 18 jh e upshot of this work, 
however, is not as simple as suggested in 
the Lisa literature. LI, for example, did 
not seem comforted by the familiar term 
“tool” when he said, “I thought a tool 
was a floppy.” We have seen many ex¬ 
amples (in the present work and in our 
prior work) of metaphor obstacles to learn¬ 
ing (such as the Lisa typing page, which 
worked very differently from a piece of 
paper). 

We have concluded that metaphors act 
as conceptual aids as much because they 
mismatch their targets as because they 
match. Pressing character keys elicits 
glowing dots on a TV screen rather than 
lines of ink on a paper; these are really very 
different effects. And typing over charac¬ 
ters on the screen replaces the prior char¬ 
acters or inserts the new characters, 
although both outcomes are unpredictable 
on the basis of literal metaphor projec¬ 
tion. Indeed, given a simple view of 
metaphor, it is remarkable that neither of 
these metaphor misfits has troubling con¬ 
sequences for learners. In fact, encounter¬ 
ing these misfits can afford a concrete op¬ 
portunity for developing an enhanced 
understanding of the electronic medium 
(such as the concept of dynamic storage). 

However, for a metaphor mismatch to 
be an efficacious learning tool, it is critical 
that it occur in the context of obvious con¬ 
sistency. Learners want and need to solve 
problems in order to learn actively, but to 
do this they need to be able to discern the 
problem. There must be a background of 
predictability for them to pick up what is 
novel. This accounts for some of the 
trouble with LisaProject we observed: The 
presentation of the application did not 
make obvious enough what was what, nor 
did it successfully draw upon what our 
learners already knew about project plan¬ 
ning. Hence, it gave them an inadequate 
basis from which to proceed. 17 

The desktop and typing page in Lisa 
were better examples. As we described 
above, in these cases the metaphor was 
obvious; predictability was high, and 
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some mismatches with the metaphor were 
detected and used to sort out problems 
during learning. Other mismatches caused 
problems, however. The notion of sta¬ 
tionery pads for folders and the require¬ 
ment to Tear Off Stationery prior to data 
entry were mismatches in the desktop 
metaphor that caused problems, as did in¬ 
visible format characters and the insert 
mode in the typing page metaphor. The 
Lisa literature stressed the deliberate 
design of the metaphor, but did not in¬ 
dicate how the Lisa designers approached 
metaphor mismatches in the interface 
despite their importance. 


W hat can we learn from Lisa? 

Lisa’s user interface design was 
a milestone in human-com¬ 
puter interaction. Indeed, we may only 
have begun to appreciate the conse¬ 
quences of Lisa’s user interface for design. 
Nevertheless, present research should 
make plain the fact that Lisa was not a 
panacea for user interface design prob¬ 
lems. The challenge is to develop a serious 
understanding of the usability problems 
and strengths of this new approach, an 
understanding that can guide the design of 
even better user interfaces. As our study 
makes clear, this is not likely to be a simple 
endeavor. User interface issues are far 
more subtle than the black-and-white of 
popular understanding. 

We have stressed troublesome aspects of 
the Lisa interface, in part because other 
discussions of Lisa focused so exclusively 
on the many positive aspects of its inter¬ 
face. But our concern is not with merely 
being balanced. Lisa can have two distinct 
influences on interface design. First, it can 
entrain simple “Lisa-mimic” designs, 
which will duplicate both the advantages 
and the problems of Lisa (and add little to 
the state of the art). But second, it can 
serve as a design lesson, a large-scale inter¬ 
face prototyping experience for “Lisa- 
based” designs, which will profit from 
both the advantages and the problems of 
Lisa. We would like to facilitate the second 
possibility. □ 
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Data-Processing Hardware for Spacecraft: 


Air Force Standard 
1750A ISA Is the New 
Trend 


Lester Byington and Doug Theis 
The Aerospace Corporation 



" iTse of Air Force 
Standard 1750A ISA 
will dominate 
spacecraft data- 
processing technology 
for the next decade, 
and this will enable 
better and more 
mature software- 
development tools to 
be used in spacecraft 
data processing. 


U ntil recently, each computer 
designed to control spacecraft 
flight was “vendor unique” in 
its hardware instruction set, which meant 
that every vendor also designed unique 
software support tools and test stations. 

The Air Force Standard 1750A Instruc¬ 
tion Set Architecture (ISA) has changed a 
similar “Tower of Babel” problem in 
avionics to a unified, cost-effective 
approach. To be certified to the Air Force 
1750A Standard, machines must be 
brought for verification testing to the 
Systems Engineering Avionics Facility 
(SEAFAC) at Wright-Patterson Air Force 
Base, Aeronautical Systems Division. The 
testing at SEAFAC includes running and 
verifying many software programs on a 
machine to determine its functional fidel¬ 
ity to the 1750A specifications. Also, a 
program based on the Digital Avionics 
Integrated System (DAIS) mix and devel¬ 
oped from avionics applications is used as 
a figure of merit to compare 1750A-certi- 
fied hardware units. 

Because of the large financial invest¬ 
ment and amount of time necessary to de¬ 
velop and staff SEAFAC, it seemed 
advantageous to the Air Force/aerospace 
community to use it as a place to certify 


An earlier version of this article appeared in the 1986 
IEEE Aerospace Applications Conference Digest, 
Session III, February 1-8, 1986, Steamboat Springs, 
Colorado. 


spacecraft computers for conformity with 
1750A. 

The availability of 1750A hardware for 
use in flight computers for spacecraft has 
many advantages: 

• The maturity of the architecture 
minimizes risk. 

• Multiple suppliers compete in the 
marketplace, which lowers costs. 

• Hardware technology insertion is 
easily done (that is, new hardware tech¬ 
nologies can be used with existing soft¬ 
ware). 

• Transportability of operational 
modules. 

• Maturing software assemblers, com¬ 
pilers, linkers, loaders, and editors in the 
process of development are available off 
the shelf. 

• Availability of 1750A hardware 
shortens delivery schedules and eases 
maintenance. 

However, certain disadvantages exist: 

• The main disadvantage is that some 
differences exist between avionics code 
and spacecraft code utilization of the 
1750A. 

• The 1750A is a 16-bit architecture 
with extensions, but not a full 32-bit ISA. 

• The 1750A may not be the best choice 
for a particular application. 

Other arguments for a standard ISA. 

The need for a standard ISA results from 
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Figure 1. Block 
diagram of the data- 
management system 
hardware located 
aboard a spacecraft. 



Figure 2. The control procedure sequences that interact between ground operations 
and on-satellite data processing. 


an increase in spacecraft subsystem in¬ 
terdependencies and from problems 
caused by lack of standardization among 
vendors. 

Increased subsystem interdependen¬ 
cies. During recent years the use of data- 
processing digital hardware in satellites 
has grown from employing single data 
processor units for stand-alone functions 
to multiple-processor configurations for 
interrelated applications. Applications 
include the control and operation of the 
various spacecraft subsystems, such as the 
power management, command and telem¬ 
etry, thermal regulation, and antenna con¬ 
trol subsystems. 

Each data-processing application has 
its own unique set of requirements, and 
these requirements often call for hard¬ 
wired, or fixed, program sequence de¬ 
signs. Quite often the control functions 
are implemented by means of a memory 
look-up table that generates output values 
as a function of input values. 

The number of data-processing appli¬ 
cations is increasing. Many of them use 
microprocessors with electronically en¬ 
coded functions that accomplish the 
necessary signal processing and control 
digitally. 

Increased data-processing capability is 
achieved by putting all the sophisticated 
logic in software, which thus reduces the 
need for hardware and gives the designers 
the flexibility of reprogrammability. The 
disadvantages of this approach are the ex¬ 
tra engineering necessary to develop the 
software and the complications of imple¬ 
menting time-shared functions that com¬ 
bine hardware and firmware. The data- 
processing hardware functions for each 
spacecraft subsystem and for the overall, 
integrated spacecraft system must be 
carefully evaluated before logic functions 
are put in software. 

Requirements unique to spacecraft. 
The increase in spacecraft subsystem in¬ 
terdependencies has produced an order of 


magnitude increase in complexity, which 
in turn has had a major impact on how 
one makes trade-offs that involve data- 
processing hardware technology. Evalu¬ 
ation and selection of the best hardware 
technology depends on such requirements 
as reliability, memory capacity, and pro¬ 
cessing speed, as well as the power, 
weight, and size of each subsystem to be 
constructed. 

Since the role of the spacecraft’s data- 
processing system is to provide the ar¬ 
chitecture necessary to integrate the 
diverse satellite subsystems, one must 
analyze the data-processing subsystems 
carefully to determine the whole system’s 
adequacy in meeting requirements. Figure 
1 shows a block diagram of a spacecraft’s 
data-management system: the hardware 
elements, and the interfaces that the soft¬ 
ware in the data-processing units uses to 
manage the embedded control operations. 
The figure is a generic example, and does 
not represent any one spacecraft. 

Operating in a spacecraft environment 
makes some unique demands of data- 


processing hardware. Reliability is the 
preeminent capability that the data- 
processing hardware must possess. The 
truly unique operation performed by the 
hardware is remote operation of space¬ 
craft on multiyear missions, which the 
hardware carries out via communication 
links for commanding the satellite and for 
reading the telemetry data from the 
satellite. This remote-control capacity 
functions by means of a special 
command-and-telemetry port integrated 
into the data-processing hardware. 
Remote control makes it possible to 
power-on or power-off the on-board 
computer: to start up or initialize the on¬ 
board computer elements, such as CPU, 
memory, and I/O; and to execute 
diagnostics of one kind or another for 
testing and for isolation of faults. These 
functions are carried out with remote- 
control switching of spare data-processor 
resources so as to activate and deactivate 
spare memory modules, CPU modules, 
power converter modules, and input-out- 
put modules. Figure 2 illustrates the 
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modes of operation, which consist of con¬ 
trol-procedure sequences, that interact be¬ 
tween ground operations and on-satellite 
data processing. (Figure 2, like Figure 1, is 
a generic example; it doesn’t represent a 
particular spacecraft.) 

The data-processing system aboard the 
satellite performs many basic functions. 
For example, a principal function is to 
make attitude-control calculations so the 
satellite will always be oriented as neces¬ 
sary for its various modes of operation. 
(Instances are acquisition control for 
nadir/sun orientation and for orbit 


adjustment.) The data-processing system 
typically monitors temperatures through¬ 
out the satellite by means of appropriately 
placed sensors. Selected monitored 
readings (for example, of propellant 
levels, temperature and pressure read¬ 
ings, and battery levels—all of which are 
used for trend logging) are then sent to 
ground operations via telemetry. Figure 
3, a generic example, shows a flowchart 
of the control program in the data- 
processing unit that directly controls the 
sequence of these on-board modes of 
operation. (The control program is writ¬ 


ten in software.) Table 1 shows the lines- 
of-code estimates for each module and 
the duty-cycle timing (that is, the fre¬ 
quency) for each module; these measures 
are used to determine performance 
margins for the data-processing unit. 

Before proceeding further, let us list a 
set of capabilities typically provided by 
data-processing units for spacecraft: 

• operational procedures to activate 
(1) the power-up sequence, (2) soft¬ 
ware initializing, and (3) check-out 
and readiness assessment of various 
subsystems; 



Figure 3. A flowchart describing the control program in the on-satellite data-processing unit that directly controls the sequence of 
on-board modes of operation. (“Cl,” “C2,” and “C3” are task commands.) 
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Table 1. Estimates of number of lines of code, of duty-cycle timing (frequency), 
and of loading capacity of the various modules of an on-satellite data-processing 
system. 


Module 

Functions 

Lines of Code 
(16-bit Words) 
Program Data 

Frequency 
(Cycles Per 
Second) 

Loading Capacity 
(KIPS*) 

Executive 
(task processing, 
scheduling, queue 
handling, and so on) 

240 

800 

10 

2.4 

Command-issuing 

processor 

700 

300 

20 

14.0 

Telemetry 

generation 

100 

500 

4 

0.4 

Telemetry 

acquisition 

100 

50 

4 

0.4 

Attitude 

determination 

1000 

200 

1 

1.0 

Attitude 

control 

1000 

500 

10 

10.0 

Power 

management 

500 

100 

1 

0.5 

Failure 

detection 

40 

100 

10 

0.4 

Totals 

3680 

2550 


29.1 


* “KIPS” stands for thousand instructions per second. 


• sequence control and timing syn¬ 
chronization for various spacecraft 
subsystems; 

• centralized scheduling and prioriti¬ 
zation of all data and command 
transmissions to and from the data- 
management subsystem; 

• storage for fixed and variable 
telemetry data for satellite monitor¬ 
ing, which is downlinked as part of 
the formatted data stream; 

• provision and maintenance of status 
and trend information on the health 
and configuration of the satellite 
resources; and 

• attitude-control computations to 
point and maneuver the vehicle. 

Implementation approaches. Current¬ 
ly, the two common approaches to imple¬ 
menting data-processing subsystems are 

• refining the requirements to the 
highest degree possible, then build¬ 


ing them into firmware (for which 
EEPROMs, PROMs, and ROMs are 
used), and 

• implementing as many of the func¬ 
tions as possible in software and 
combining the software with micro¬ 
processors and RAM chips to 
achieve the maximum in flexibility 
and allow for later changes as re¬ 
quired. 

(What we mean by ‘ ‘the maximum in flex¬ 
ibility” is a design with the proper balance 
between the portion—amount—of the 
design implemented in hardware and the 
portion implemented in software.) 

For most data-processing subsystems, 
designers of satellite systems now under 
development use a combination of both 
approaches. It is important to note that 
either too much or too little flexibility 
can impact the success of the satellite sys¬ 
tem. There are obviously clever ways to 
use flexibility, but there are also ways 


that a flexible design can be a problem in 
spacecraft applications. An example of a 
too flexible design is one in software with 
functions that require complicated in¬ 
tegration algorithms when a hardwired- 
circuit functional equivalent would pro¬ 
vide faster processing—probably with 
less engineering investment required for 
development. 

From our experience of many satellite 
programs, we are of the opinion that 
degree of flexibility should be a con¬ 
sideration in building data-processing 
subsystems. It is usually not practical, 
however, to use flexibility as a criterion 
because a quantitative figure of merit for 
it is difficult to derive. 


A survey of the latest 
computers/ 
microprocessors that 
are candidates for 
spacecraft 

We recommend that technical evalua¬ 
tion consist of two major concurrent 
phases: 

• deriving processing requirements 
from the application requirements, 
and 

• a screening evaluation of what is 
currently available in qualifying 
data-processing hardware and soft¬ 
ware. 

For this methodology, we recommend 
evaluation of the following 10 major 
technical criteria: 

• throughput, 

• memory and I/O capability, 

• reliability, 

• power, 

• weight and size, 

• radiation tolerance, 

• software development-and-support 
tools, 

• development risk, 

• producibility, and 

• qualification/delivery schedule. 

Tables 2 and 3 are surveys of 1750A 

computers that are candidates for use in 
spacecraft and of space-qualified micro¬ 
processors, respectively. “Space qualifi- 
able” is the key phrase used to indicate 
that the electrical attributes and the 
packaging and physical construction 
were specifically designed to meet the re¬ 
quirements of spacecraft operation. 
Those requirements involve such con¬ 
siderations as thermal management, 


November 1986 


53 




reliability and redundancy, and environ¬ 
mental suitability (primarily capability 
for withstanding extremes of radiation 
and temperature). It must be understood 
that substantial time and budget will 
typically be required before any of the 
computers in these tables are ready for 
integration into a particular spaceborne 
application. Some designs are available 


and others are in advanced development. 
Note that none of the candidate space¬ 
craft computers in Table 2 are actually 
available off the shelf. 

The microprocessors surveyed include 
1750A devices as well as non-1750A 
devices. Any practical comparison of 
1750A computers and/or chips should 
include coverage of additional considera¬ 


tions, such as the specific 1750A options 
that are available. Included in the 1750A 
options are such important capabilities 
as the memory management unit (to han¬ 
dle up to 1M words), block protection (to 
provide access protection with page 
register locks and key, as well as exe¬ 
cute/write protection), start-up ROM 
(which is EEPROM-loadable by means 


Table 2. Box computers that conform to Air Force 1750A Standard ISA and are candidates for use in spacecraft applications. 

Manufacturer and model 


Control 

Delco 

General 

IBM 


Data 

(Magic V, 

Electric 

(1750A 


(SCP) 

aka M572) 


avionics model) 

Characteristics 

SEAFAC certification 

Yes 

Yes 

Yes 

Yes 

Performance rating from 

DAIS mix (analysis was done 
by vendor) 

750 KIPS* 

700 KIPS* 

550 KIPS* 

1 MIPS** 

RAM 





Access time 

150 ns 

180 ns 

300 ns 

70 ns 

Size (where RAM qualifies 

16K 

16K 

16K 

(64K RAM is not 

for spacecraft) 




yet radiation hard.) 

Manufacturer (where 

RCA or VHSIC 

RCA 

RCA 


RAM qualifies for 
spacecraft) 

Technology Corp. 




Chip technology 




NMOS 

MOS and/or bipolar 

CMOS/SOS 

CMOS 

Bipolar 

Custom VLSI or part 

Custom 

Custom 

2901 (4-bit ALU) 

Custom 

(manufacturer) 

(Rockwell) 

(Motorola) 

(AMD and 

(IBM) 




others) 


Feature size 

VLSI (2 urn) 

VLSI (3 fan) 

MSI 

VLSI (2 fan) 

Parts availability 

2 out of 5 

Now 

Now 

Now 

Parts meet MIL-STD-883C*** 
Cross-strapping of box 

Yes 

Yes 

Yes 

Yes 

for dual redundancy 

No 

Yes 

Yes 

No 

Estimate of capacity of model 
when used in spacecraft 
applications 

128K words 

512K words 

128K words 

128K words 

(Estimate based on model’s' 
Power 

24 watts 

55 watts 

80 watts 

95 watts 

Weight 

7 lbs. 

28 lbs. 

18 lbs. 

20.8 lbs. 

Size) 

0.7 cubic ft. 

0.46 cubic ft. 

0.3 cubic ft. 

0.27 cubic ft. 

*“KIPS” stands for thousand instructions per second. 
**“MIPS” stands for million instructions per second. 




***MIL-STD-883C is a measure of a chip’s electrical capability and the temperature ranges it can withstand. 
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of a computer test interface), and the 
memory fault status register (MFSR). 

These surveys contain point design in¬ 
formation that is dependent on existing 
technologies; one has to realize that 
capabilities and technologies will change. 
The vendors listed in the two tables may 
redesign their offerings or change perfor¬ 
mance trade-offs. 


Since only a small quantity of equip¬ 
ment is needed for spacecraft data- 
processor systems, and since this equip¬ 
ment must meet highly specialized 
environmental specifications, it is expen¬ 
sive and difficult to maintain sources of 
available components. The equipment is 
expensive because spacecraft applica¬ 
tions require 


Manufacturer and model 

Litton/Tracor 
(Radiation-hard 
1750A model) 

RCA 

(SPC 1750A) 

Teledyne 

(750S) 

SCI Technology 
(Astro 1750A) 

Characteristics 

Yes 

Yes 

Yes 

Yes 

400 KIPS* 

530 KIPS* 

550 KIPS* 

500 KIPS* 


200 ns 

170 ns 

150 ns 

110ns 

16K 

16K 

16K 

16K 

Sandia or RCA 

RCA 

Sandia 

Honeywell 


I CMOS/SOS 

1 

CMOS/SOS 

Bipolar and 
CMOS versions 

CMOS/SOS 

j GPU & gate arrays 

GPU & gate arrays 

2901 (4-bit ALU) 

MDC281 

* (RCA) 

(RCA) 

(AMD, Sandia, 
and others) 

(custom chip set) 
(McDonnell Douglas) 

(4 Mm) 

(4 Mm) 

(2 Mm) 

(4 Mm) 

j Now 

Now 

Now 

Now 

| Ye s 

Yes 

Yes 

Yes 

j ; Yes 

Yes 

Yes 

No 

64K words 

512K words 

768K words 

192K words 

39 watts 

26 watts 

197 watts 

50 watts 

14 lbs. 

33 lbs. 

78 lbs. 

15 lbs. 

0.40 cubic ft. 

0.88 cubic ft. 

1.12 cubic ft. 

0.24 cubic ft. 


• careful screening of qualified com¬ 
ponents; 

• thermal-vacuum designs; 

• designs that must meet hostile en¬ 
vironments; 

• extensive analysis of designs for 
reliability; 

• major engineering to minimize pow¬ 
er, weight, and size; and 

• large costs incurred in making devel¬ 
opments that are unique to this ap¬ 
plication. 

In addition, the natural cycle for improv¬ 
ing and upgrading satellite systems adds 
to design complexity and makes develop¬ 
ment engineering even more prone to 
costly changes, additions, and other 
problems. 

The status of spacecraft 
computer software 

Software difficulties can also be 
minimized by use of a standardized hard¬ 
ware ISA. The most popular architecture 
used for this purpose in spacecraft is the 
Air Force Standard 1750A. 

(The Army and Navy also have ISA 
standards, namely the Militarized Com¬ 
puter Family (MCF) and the Navy 
AN/UYK-44.) 

Problems. A good choice of program¬ 
ming languages and software support 
tools has been lacking for development of 
code for use in spacecraft. The reasons are 
several. In the past, Government had to 
pay for vendor-unique software support 
tools and the related software for each 
embedded computer application project. 
Providing extensive software support for 
each individual computer architecture was 
very expensive and time-consuming. In 
addition, there has been a gradual but 
significant increase in the sophistication 
of programming-support environments. 

Minimal memory capability and lack of 
off-the-shelf compilers meant that assem¬ 
bly language coding was used almost ex¬ 
clusively, since the number of lines of code 
needed for spacecraft data-processing 
functions is relatively small (typically 
from 4K to 32K 16-bit words) and mature 
compilers for vendor-unique ISAs are 
usually unavailable. Although compilers 
allow development that is less costly per 
line of code than do assemblers, the 
resulting compiler-generated machine 
code is generally less efficient because it 
takes more memory locations and because 
processing speed is not as fast. Great ef- 
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fort is taken in spacecraft-application 
implementations to squeeze as much as 
possible in a small amount of memory and 
to keep adequate throughput time mar¬ 
gins for later processing growth. With the 
increasing size and complexity of space¬ 
craft data-processing applications comes 
an obvious need to use good compilers 
and associated programming environ¬ 
ments. With application programs grow¬ 
ing in size and complexity, assembly 


coding has to give way to the use of high- 
level languages and their associated devel¬ 
opment environments. 

Software for 1750A machines. At pres¬ 
ent, Jovial J73 is the only DoD-approved 
high-level language for which mature pro¬ 
duction-quality compilers are available 
for 1750A machines. DoD plans to re¬ 
place Jovial (and all other languages used 
for embedded computers) with Ada (MIL- 


STD-1815A). At the present time there are 
at least six vendors (Tartan Labs with Pro¬ 
prietary Software Systems, Intermetrics, 
Verdix, Telesoft, ACT-Advanced Com¬ 
puter Techniques, and Rationale 
Machines with TLD Associates) working 
on Ada compilers for the 1750A ISA, and 
the first products are expected next year. 
MIL-STD-1750A is currently being 
upgraded, and MIL-STD-1750B is ex¬ 
pected to be completed and published in 


Table 3(a). Space-qualifiable microprocessors certified under Air Force Standard 1750A. 


Manufacturer and Model 



Fairchild 

(9450) 

McDonnell Douglas 
(MDC281) 

Mikros 

(MKS 1750/S) 

Performance 

Semiconductor 

(94C50) 

Characteristics 

Word length 

16 

16 

16 

16 

Technology 

Bipolar, I 2 L 
(Fairchild; 3 /um) 

CMOS/SOS 

(McDonnell Douglas; 4 /un) 

CMOS/SOS 
(RCA; 2 Aim) 

CMOS 

(Performance 

Semiconductor; 

1.25 Aim) 

Instruction 

set 

architecture 

1750A 
(2 chips, 
includes MMU) 

1750A 
(4-chip set, 
includes MMU) 

1750A 
(11-chip set, 
includes MMU) 

1750A 
(2 chips, 
includes MMU) 

Fixed/floating point 
arithmetic 

Floating point 

Floating point 

Floating point 

Floating point 

Processing speed 
(measured by DAIS 
mix) 

700 KIPS* 

750 KIPS* 

260 KIPS* 

1000 KIPS* 

Memory cycle time 
(Clock) 

100 ns 
(20 MHz) 

200 ns 
(24 MHz) 

100 ns 
(40 MHz) 

35 ns 
(20 MHz) 

Memory capacity 

128K words to 1M 

64K words to 1M words 

64K words to 

1M words 

64K words to 

1M words 

Direct 

memory 

access 

Yes 

Yes 

Yes 

Yes 

Power supply 
required 

5V 

5V or 12V 

5V 

5V 

Power consumption 

3 watts 

2 watts 

2 watts 

2 watts 

Availability 

Now 

Now 

Now 

1st qtr. 1987 

In production 

Yes (12, 13, 14 

MHz versions) 

Small lots 

Bendix 

50 BDS 


*“KIPS” stands for thousand instructions per second. 
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approximately two years. The goals for 
1750B are that it will more efficiently 
support Ada and that it will be an upward- 
compatible extension of 1750A. Hardware 
builders, compiler vendors, contractors, 
and Government are actively working 
together through users groups to meet 
these goals. 

Software support tools are evolving for 
1750A. The most important ones are the 
basic assembler and the linkage editor. In 


general, today’s assemblers come with ad¬ 
ditional features, such as directives (or 
pseudo-operations to facilitate house¬ 
keeping and documentation) and macro 
capability. Also, today’s linkers and 
loaders have features that can be designed 
to support 1750A high-level language 
modules as well as most of the 1750A op¬ 
tional hardware features. In addition to 
the assembler and linkage editor, a sym¬ 
bolic debugger and a 1750A instruction 


simulator are needed. 

General software support for space¬ 
craft. Until very recently, each spacecraft 
computer application had its own custom¬ 
ized executive scheduler (that is, a rudi¬ 
mentary real-time operating system) of a 
few thousand lines of code or less. Now 
that small (4K- to 8K-word) real-time 
operating systems (such as Intel’s RMS, 
Motorola’s Versados, Proprietary Sys- 


Table 3(b). Space-qualifiable microprocessors not certified under Air Force Standard 1750A. (Note: The RCA 1802 Series, which 
was the first series of microprocessors in space, is no longer available.) 


Manufacturer and Model 


Sandia 

(SA3000) 

Fairchild 

(9445) 

Harris 

(80C85/80C86) 

Texas Instruments 
(9000) 

Rockwell 

(AAMP) 

Characteristics 

Word length 

8 

16 

8/16 

16 

16 

Technology 

CMOS 

Bipolar, I 2 L 

CMOS 

Bipolar, I 2 L 

CMOS/SOS, CMOS 

Instruction set 
architecture 

Vendor-unique 
(Intel 8085) 

Vendor-unique 
(Data General 
Nova) 

Vendor-unique 
(Intel 8085, 8086) 

Vendor-unique 

Vendor-unique 

Fixed/floating 

point 

arithmetic 

Fixed 

Fixed 

Fixed 

Fixed 

Floating point 

Shortest 
instruction- 
execution time 

800 ns 

250 ns 

400 ns 

500 ns 

500 ns 

Memory cycle 
(Clock) 

200 ns 
(5 MHz) 

300 ns 
(20 MHz) 

500 ns 
(5 MHz) 

125 to 100 ns 
(8 to 10 MHz) 

100 ns 
(20 MHz) 

Memory capacity 

64K bytes 

128K bytes 

64K/1M bytes 

128K bytes 

64M bytes (24-bit 
address bus) 

Direct memory 
access 

Yes 

Yes 

Yes 

Yes 

Yes 

Power supply 
required 

10V 

(30 ma, 10V) 

5V 

(400 ma, 1.3 V) 

5V 

(50 ma, 5V) 

1.25 V 

(100 ma, 1.25 V) 

5V 

(40 ma maximum) 

Power consumption 0.3 watts 

1.2 watts 

0.25 watts 

0.5 watts 

0.2 watts 

Other comments 

2 x 10 5 rads, 
SEU* test data 
(5V) 

1 x 10 5 rads, 
SEU* test data 

1 x 10 4 rads, 
SEU* test data 

2 to 4 x 10 4 rads, 
SEU* test data 

reached 600 KOPS, 
DAIS mix 

Availability 

Yes 

Yes 

Yes 

Yes 

Yes 

*“SEU” stands for single-event upset. 
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terns Software’s Escape, and Hunter and 
Ready’s VRTX) are available, they can be 
used for their efficiency and for their 
capacity to handle the additional capabil¬ 
ities that will be provided as satellite- 
applications software grows in size and 
complexity. 

There is a definite need for software 
design and configuration-management 
tools to support the development, track¬ 
ing, and documentation needs of any ma¬ 
jor systems project. Traditionally, these 
functions have been provided by the 
operating systems of host development 
computers, but as the use of Ada in¬ 
creases, greatly expanded support for 
them and for related functions will be 
provided by Ada Programming Support 
Environments (APSEs), which are cur¬ 
rently under development and are near¬ 
ing completion. 

Important architecture 
issues 

One architecture issue is whether the 
data-processing subsystem should be cen¬ 
tralized, distributed, or a combination of 
the two. This is a very difficult technical 
subject to resolve for many reasons. The 
foremost is that the spacecraft is under 
remote control, and to ensure command 
prioritization and synchronization of 
resources, some sort of centralized exec¬ 
utive monitor (that is, a digital hardware 
box) is required. If control is distributed, 
there is much more difficulty in ensuring 
that prioritization and synchronization 
can be maintained under all conditions. 
Secondarily, because graceful degradation 
and resource management are related to 
reliability and survivability, their in¬ 
terdependency issues are so complicated 
that the designer will want to hardwire 
Restart and Reset in some guaranteed fail¬ 
safe way. 

In any major data-management subsys¬ 
tem for spacecraft, there is a need to 
control and operate data resources, par¬ 
ticularly the spare redundant-module con¬ 
figurations that are required to achieve the 
high reliability satellite programs require. 
“High reliability” means a high probabil¬ 
ity of success (typically .995) that is based 
on a reliability analysis that takes into 
account the mean time between failure 
(MTBF) rates of the parts and the internal 
circuit architecture. The design of on¬ 
ground computer systems is based on 
availability of subsystems and mean time 
to repair (MTTR), as well as MTBF. The 


data-processing units of on-ground com¬ 
puters do have the typical features built 
into flight computers for maintainability 
and repairability, such as extensive card 
troubleshooting and readily accessible 
testpoints, but they do not have features 
for maintaining equipment in a weightless 
environment. Maintenance capability for 
on-orbit repairs has really not been a 
design requirement except for Shuttle, 
Interim Upper Stage, and Space Station 
spacecraft. 

To minimize the impact of the major 
factors of power, weight, and size, state- 
of-the-art spacecraft computers use dual 
redundant and internally cross-strapped 
configurations to achieve maximum reli¬ 
ability. This method is more reliable than 
a dual string of separate computer boxes. 
Spacecraft computers operate with one set 
of modules in a string and with the other 
modules as spares in standby, or inactive, 
mode. Operation is different for launch 
computers, in which both computer strings 
are in fail-safe operation. The switchover 
time that elapses between operating one 
computer string and bringing up an inac¬ 
tive string is adequate for on-orbit opera¬ 
tions, but not for launching. However, 
dual-operation computer strings are being 
seriously considered for on-orbit use to 
eliminate the problem of upsets caused by 
radiation (examples of such disturbances 
are single-event upsets, or SEUs, brought 
about by cosmic ray particles). Also, dual- 
operating computer strings may be neces¬ 
sary in future orbiting satellites to provide 
increased processing-throughput capacity. 

Control of data-management resources 
for spacecraft is performed by specially 
designed hardwired digital boxes that use 
sequencer logic or a microprocessor for 
this purpose. Such control is not per¬ 
formed by the flight computer, which is 
located on-board (primarily to manage 
the attitude-control subsystem functions.) 
The control boxes for the data-manage¬ 
ment subsystem are used in conjunction 
with the flight computers and the embed¬ 
ded microprocessor board computers. 
The trend to put these functions in the 
control unit will probably continue for the 
next decade. 

Buses. Describing and evaluating bus 
architectures and hardware topology for 
data-management subsystems is much 
more difficult than for memory units, 
processors, or software. Bus-structure 
and hardware-topology issues arise at 
many different levels, and the engineering 
requirements are significantly different 


for each of the various levels (for example, 
for box-to-box buses, module-to-module 
buses, and interchip bus-connection struc¬ 
tures). Bus standardization can be 
specified to various degrees, and for 
various circuit technologies (for example, 
TTL or CMOS). The more universal the 
bus standard, the greater the chance that 
some specific application requirement will 
drive a user to modify the standard to 
achieve higher performance or to meet 
some unique requirement, such as a spe¬ 
cific fault-handling need. As an added 
complication, most users want very high 
data transfer rates, but may not know 
whether the processing-time and over¬ 
head-time delays negate the benefits of the 
faster transfer rates. Bus loading can, of 
course, be a major problem, but often a 
higher data-transfer rate does not solve 
the basic throughput problem because the 
protocol overhead and software process¬ 
ing may be the major limiting factors. 

Designs for data-processing hardware 
incorporate data and control paths with 
either dedicated (parallel or serial) or mul¬ 
tiplexed buses. The trade-off is between 
higher speed with more hardware or less 
hardware with slower speed. Combining 
parallel addressing with either parallel or 
serial data transfer can lead to good design 
choices (depending on the performance 
and redundancy requirements). Parallel 
data paths require more cabling and cir¬ 
cuitry, and need more careful engineering 
to ensure that time skew and crosstalk do 
not corrupt data. Serial data paths require 
sequencing the data words and control 
words onto the serial channel, and neces¬ 
sitate parallel-to-serial and serial-to-paral- 
lel logic hardware at both ends of the 
channel. For example, if the avionics 
1553-C serial lM-bps bus standard is 
used, minimum cabling is necessary, but 
the overhead associated with decoding 
transmitter and receiver addresses may 
reduce speed and make this bus inefficient 
for a spacecraft that must meet more 
stringent real-time requirements. Another 
example is the star data-bus architecture, 
which has the advantages of low protocol 
overhead and no contention, but the dis¬ 
advantages of more cabling and connec¬ 
tors than the 1553-C. 

T he most noteworthy future trend 
in approaches to designing data- 
processing hardware for space¬ 
craft will be the increasing use of micropro¬ 
cessors as sophistication and complexity 
grow. The challenge is to incorporate mi¬ 
croprocessors effectively, and by using 
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designs that are testable and verifiable 
under all conditions. 

Some specific trends in data-processing 
technology for spacecraft for the next 
decade: 

• Standardized IS As will dominate, 
with the result that better and more 
mature software development tools can be 
applied to projects. 

• High-reliability and high-survivabil¬ 
ity requirements will dictate continued 
major use of nonvolatile memory tech¬ 
nology. 

• Spacecraft data-bus standardization 
should finally evolve, necessitated by the 
increasing use and number of micropro¬ 
cessors. 

To date, with few exceptions, assembly 
language source coding has been used for 
spacecraft applications. The 1750A ISA 
already has compilers, editors, loaders, 
and linkers to facilitate applications-soft- 
ware development, which is a necessary 
trend; a standard Air Force ISA allows it 
to happen more expeditiously. 

Nonvolatile, long-retention, radiation- 
resistant memories are absolutely essential 
to both recovery functions and some 
autonomous operations—and therefore 
to spacecraft survivability. Nonvolatile- 
memory capacity below 1M 16-bit words 
is practical, for example, with such solid- 
state memories as lM-bit or 4M-bit 
magnetic bubble chips. Greater memory 
capacities can be achieved with magnetic 
tape recorders, given that the access time 
is adequate and reliability needs can be 
met. The weight and size of solid-state 
devices may be excessive above 1M 16-bit 
words, but to gain similar capacities, tape 
recorders require only more tape. 

Lastly, approaches to data-bus design 
need better analysis and trade-off deci¬ 
sions prior to development to ensure that 
a bus’s loading capacity and efficiency are 
adequate for a working data-processing 
subsystem. There is justification for serial 
and parallel data bus standards, such as 
those found in commercial industry, and 
one possible solution is to use military 
standards, such as 1553-C. R&D in this 
area needs to be increased. □ 
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Can software for the 
Strategic Defense 
Initiative ever be 
error-free? 


Ware Myers, Contributing Editor 


The degree of success 
of the President’s 
initiative depends 
heavily on the extent 
to which its battle 
management software 
can be made reliable. 


T o destroy enemy missiles in their 
boost phase, in space during their 
midcourse period, or in the air 
during their terminal phase will require a 
worldwide system of sensors, weapons 
platforms, and communications. Early 
estimates indicate that the command, con¬ 
trol, and communications system binding 
all these elements together will be based 
upon the most massive software project 
ever attempted. 

“Because of the extreme demands on 
the system and our inability to test it 
[under conditions of operational use], we 
will never be able to believe, with any con¬ 
fidence, that we have succeeded,” as¬ 
serted David L. Parnas, when he resigned 
from the SDI Organization’s Panel on 
Computing in Support of Battle Manage¬ 
ment June 28,1985. According to Parnas, 
professor of computer science at the Uni¬ 
versity of Victoria in British Columbia, 
“Nuclear weapons will remain a potent 
threat.” 1 

“It is much too soon for gloom,” 
countered Frederick P. Brooks, author of 
The Mythical Man-Month and professor 
of computer science at the University of 
North Carolina, in an appearance before 
a congressional committee. 2 “I see no 
reason why I or any other competent, ex¬ 
perienced, better software manager than I 
am—and there are a lot of them—could 
not undertake to build such a system.” 


The House Appropriations Committee, 
considering funds for SDI, noted that 
“sizable problems exist in designing and 
testing software programs for an SDI sys¬ 
tem.” 3 The committee presented nine 
questions on this theme to the SDI 
Organization, or SDIO. In his reply Lt. 
Gen. James A. Abrahamson, USAF, 
SDIO Director, admitted that no com¬ 
plex system ever built has achieved 
“perfection.” 4 However, many sys¬ 
tems—for such critical areas as space 
operations, military and commercial fly¬ 
ing, air traffic control, communications, 
banking, and medicine—have been “cor¬ 
rect” in the sense that the systems were 
“effective” or “reliable,” he added (his 
emphasis). 

In December 1985 the panel from which 
Parnas resigned concluded that the “com¬ 
puting resources and battle management 
software for a strategic defense system are 
within the capabilities of the hardware 
and software technologies that could be 
developed within the next several years.” 5 

So, there are differences of interpreta¬ 
tion and of opinion. One factor the debate 
has brought out, however, is the critical 
position of the software in the strategic 
defense effort. In the panel’s judgment, 
“the anticipated complexity of the battle 
management software and the necessity to 
test, simulate, modify, and evolve the sys¬ 
tem make battle management and com- 
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mand, control, and communication 
(BM,C3) the paramount strategic defense 
problem.” 

The larger question before us, as 
Brooks put it in a panel session at the 
Eighth International Conference on Soft¬ 
ware Engineering in London on August 
30,1985, is “How good is good enough? ’ ’ 

The problem of “good enough” is that 
in an exchange of nuclear missiles, if we 
take 99.9 percent as an effective perfor¬ 
mance and if 10,000 weapons were 
directed at us, about 10 nuclear bombs 
would get through. Of course, that is not a 
pleasant prospect. 

Errors in the software, however, are not 
identical to leaks in the shield. A software 
error, for example, may result only in a 
misplaced element on a readout display. It 
would be more serious if the system 
assigned two weapons against one threat 
when it should have assigned one, Brooks 
told the Senate committee, but “that is 
not the kind of thing that one would lose 
sleep over.” 

More serious still would be an error 
leading to the failure to destroy a target 
during the boost phase. Still, correct soft¬ 
ware in later tiers of the system might take 
out that target. Yet that is a significant er¬ 
ror if it leads to overloading the subse¬ 
quent tiers. The worry is that a few thou¬ 
sand errors in the deployed software 
would lead to a few hundred significant 
failures that might finally result in 10 
leaks. 

The problem of errors 

The raw cost of such a system [referring to the 
SDI software] is therefore less important than 
the feasibility and methods of finding and cor¬ 
recting errors in it. 

—Harold Brown, Secretary of Defense, 
1977-81® 

Errors in large, complex software sys¬ 
tems are created in the process of formu¬ 
lating requirements, writing specifica¬ 
tions, designing software, and writing 
code. They are removed by self-checking, 
walkthroughs, inspections, design re¬ 
views, module testing, and integration 
testing. More errors are created in the 
course of the reprogramming required to 
remove earlier errors. Software goes into 
operational use with some errors remain¬ 
ing. They are gradually discovered when 
the system malfunctions, and are then 
corrected, introducing still more errors. 

Furthermore, the first release of a large, 
complex system normally does not exactly 
satisfy the problems it was created to 
solve. It must be modified to achieve a 


better fit to its problem set, and in the 
process of modification more errors are 
created and only some of them are fixed. 
Next it turns out that the problems 
themselves are changing, leading to the 
enhancement of the software. In this 
process, we are no longer surprised to find 
out, errors are created and again only 
some of them are fixed. But always some 
number of errors, perhaps fairly small, 
remains to be found when they turn up 
under some unusual combination of 
operating circumstances. A system user 
can never be certain that all of the errors 
have been found and fixed. 

Numbers of errors. The number of 
errors created is not insignificant. In 
several studies errors were found to range 
from 30 to 85 per thousand delivered 
source instructions. 7 

The variation in the number of errors 
created depends upon the type of soft¬ 
ware, the size of the system, the definition 
of the term “error,” the different proce¬ 
dures organizations have for collecting 
errors, and other factors. For our present 
purpose the point is there are a lot of 
errors. 

Fortunately, most of them are found 
and fixed in the course of development 
and testing, before release. For example, 
according to Dennis W. Fife of the 
National Bureau of Standards, delivered 
software for large systems typically has 
errors at a rate of one in every 300 pro¬ 
gram statements, or 3.3 per thousand. 

A two-million line system developed 
and maintained by Bell Communications 
Research has experienced a range of 0.8 to 
1.3 field defects per thousand lines of new 
and changed source code on three releases 
per year over a recent four-year period. 8 A 
Bell Laboratories survey of software 
faults found that errors typically range 
from 0.5 to 3.0 occurrences per 1000 lines 
of program, according to T. R. Thomsen, 
president of AT&T Technology Systems. 9 

System size. Exacerbating the error 
problem in the case of a massive system 
such as SDI is the fact that the number of 
errors introduced per thousand lines of 
code increases exponentially with the size 
of the software system. 10 This finding was 
based on an analysis of error data from 
past software projects, but it is also 
consonant with common sense. One 
expects proportionately fewer errors in a 
small, intellectually manageable program 
than in a large, complex one. 

The quantity of software needed by 
SDI was termed “very large” (order of 10 


million lines of code) by the Defensive 
Technologies Study Team (Fletcher panel) 
appointed by the Secretary of Defense in 
1983 to investigate the feasibility of the 
SDI concept. 11 Of course, this estimate is 
little more than a guess as there was no 
system design at the time it was made. 
Other guesses have ranged upward to 30 
million lines and even 100 million lines. If 
the low error rate, 0.5 errors per thousand 
lines, cited by Thomsen is applied to the 
low estimate, 10 million lines, SDI would 
contain about 5000 errors at the time it 
became operational, or even more, allow¬ 
ing for an exponential increase in the 
quantity of errors. 

Bell Laboratories’ experience with the 
only previous large-scale anti-ballistic 
missile system, Safeguard, suggests that it 
succeeded in bettering this error rate. The 
system, developed between 1969 and 
1975, consisted of 2,261,000 assembly- 
language instructions of which 789,000 
were real-time software. Approximately 
5000 software design problems serious 
enough to affect “the primary perfor¬ 
mance objective of the system” were iden¬ 
tified and corrected prior to the activation 
of the system. 12 As an indication of the 
effort error detection and correction 
takes, code and unit testing and 
integration testing of the real-time soft¬ 
ware consumed 60 percent of the staff 
resources devoted to this portion of the 
project. 

Following deployment of the system 
around the Minuteman silos in North 
Dakota in 1975 a set of demonstration 
tests at the site revealed only one further 
serious error. Whether additional errors 
would have been revealed by long-term 
operational use cannot be known because 
the system was decommissioned in 1976, 
apparently because an opponent could 
have easily overwhelmed it by increasing 
the number of attacking missiles beyond 
its defensive capabilities. 

Safeguard was a terminal phase anti- 
ballistic missile defense system and it was 
limited by the ABM treaty of 1972 to only 
100 interceptors. Consequently, it was 
much smaller than the SDI system, which 
will operate over three tiers—boost phase, 
midcourse, and terminal—and will 
presumably be capable of coping with 
some thousands of intercontinental ballis¬ 
tic missiles. Hence it seems reasonable to 
assume that the SDI software will be many 
times larger than the Safeguard software 
and the effort to remove errors will need 
to be much greater. 


62 


COMPUTER 







Why software is 
unreliable 

I am not a modest man. I believe that I have as 
sound and broad an understanding of the prob¬ 
lems of software engineering as anyone that I 
know. If you gave me the job of building the 
system, and all the resources that I wanted, I 
could not do it. I don’t expect the next 20 years 
of research to change that fact. 

— David L. Parnas 

Conventional software development 
methods—the methods in wide use in 
both industry and the military—are not 


adequate for building large real-time soft¬ 
ware systems that must be reliable when 
first used, Parnas asserted. The conven¬ 
tional method begins with the pro¬ 
grammer trying to “think like a 
computer.” It works well on small prob¬ 
lems that do not lead into extensive 
branching and looping. 

“As soon as our thinking reaches a 
point where the action of the computer 
must depend on conditions that are not 
known until the program is running, we 
must deviate from the method by labeling 
one or more of the actions and remem¬ 
bering how we would get there.” Parnas 


explained. 1 “As soon as we introduce 
loops into the program, there are many 
ways of getting to some of the points and 
we must remember all of those ways. As 
we progress through the algorithm, we 
recognize the need for information about 
earlier events and add variables to our 
data structure. We now have to start 
remembering what data mean and under 
what circumstances data are meaningful. 

“As we continue in our attempt to 
‘think like a computer,’ the amount we 
have to remember grows and grows. The 
simple rules defining how we got to cer¬ 
tain points in a program become more 


Attaining 99.9 percent reliability 

The number of errors created and later found and fixed has 
been modeled as a Rayleigh curve. 1 (See Figure A.) The y axis 
represents errors per month and the x axis, time in months. 

This curve was projected on the basis of a real-time command 
and control system of 1 million lines of source code, intended 
to be roughly representative of one of the subsystems of SDI. 

The vertical lines indicate milestones during development 
and operation: 

(1) Preliminary design review, 

(2) Critical design review, 

(3) First code complete, 

(4) System integration test, 

(5) User-oriented system test, 

(6) Initial operational capability, 

(7) Full operational capability (95 percent reliability level), 

(8) 99 percent reliability level, and 

(9) 99.9 percent reliability level. 

For a system of this size and complexity, reaching the 95 per¬ 
cent reliability level, meaning that 95 percent of the errors have 
been removed, takes about five years. Then about 2.5 years of 
operation and maintenance are required to reach the 99.9 per¬ 
cent reliability level. 

If the other SDI subsystems are independent of this one and 
of each other, they could be done in parallel, but some addi¬ 
tional time would be needed to integrate all of them. If the sys¬ 


tems are not completely independent, some of the devel¬ 
opment would have to be done in serial, perhaps stretching the 
time to reach 99.9 percent reliability out to 10 years or more. 

The cumulative errors out to full operational capability (95 
percent reliability) number 6022, and out to 99.9 percent 
reliability, 6333 (Figure B). At full operational capability 316 er¬ 
rors remain to be found and even at the 99.9 percent point, six 
errors probably remain. If the entire SDI software system is 
about 10 times this size, the total number of errors would be in 
the vicinity of 60,000 and about 60 errors would remain at the 
99.9 percent point. 

The computation of this error-rate curve is based upon past 
error data from a limited number of systems. Moreover, the 
data was not always uniformly defined. Consequently, we do 
not claim a high degree of accuracy for the projection. Rather 
the curve is illustrative of the way in which errors are created 
and removed until finally 99.9 percent of them have been found 
and fixed. 
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Figure A. Expected error rate. Percent reliability: 7 = 95; 
8 = 99; and 9 = 99.9. 


Figure B. Total expected errors. Percent reliability: 
7 = 95; 8 = 99; and 9 = 99.9. 
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complex as we branch there from other 
points,” he continued. “The simple rules 
defining what the data mean become 
more complex as we find other uses for ex¬ 
isting variables and add new variables. 
Eventually, we make an error.” 

In a system such as SDI there will be 
two further sources of complications, 
concurrency and multiprocessing, to add 
to the programmer’s thinking load, Par- 
nas pointed out. He concluded that 
“writing and understanding very large 
real-time programs by ‘thinking like a 
computer’ will be beyond our intellectual 
capabilities.” 

SDI especially difficult. All large, com¬ 
plex software systems are very difficult to 
build, but SDI software has added 
elements of difficulty, Parnas said at 
Compcon Spring last March. First, its al¬ 
gorithms must be matched to assumptions 
about the enemy’s target and decoy char¬ 
acteristics. We can never be sure that we 
have got our algorithms right, because the 
opponent controls these characteristics 
and can change them from time to time. 

Second, the opponent can arrange to 
overload the system. To meet strict real¬ 
time deadlines, the SDI programs would 
have to have built-in schedules, computed 
in advance. These schedules would have 
to be based upon prior assumptions about 
the nature of the attack. If the enemy 
changes that nature, perhaps by directing 
an unexpectedly large number of missiles 
at one sector, he could overload those 
computers, causing them to hang up com¬ 
pletely or at a minimum to be incapable of 
tracking and targeting some share of the 
missiles. 

Third, putting computers and com¬ 
munication links in space is unusually ex¬ 
pensive, Parnas noted. Moreover, they are 
unusually vulnerable. This difficulty is 
compounded by the need to have redun¬ 
dant elements to enhance reliability and a 
sufficient number of units to overcome 
countermeasures. “High reliability can be 
achieved only if failures of individual 
components are statistically independent,” 
he added. “For a system subject to coor¬ 
dinated attacks, that is not true.” 

Product verification. Noting that there 
are, nevertheless, large programs that 
work reliably enough to be used, Parnas 
explained this apparent anomaly by 
reference to the trial-and-error nature of 
programming. Programs are not designed 
to be error-free; they are tested into some 
degree of reliability and that degree is later 


enhanced by removing errors during 
operational use. 

Engineers make products reliable by a 
combination of mathematical analysis, 
exhaustive case analysis, or prolonged 
testing, Parnas said. These methods fall 
short in the case of software. The tools for 
mathematical analysis work best on con¬ 
tinuous functions, he explained. Software 


is a discrete-state system that cannot be 
described by these functions. 

Another analytical approach is to prove 
a program, but “the best tools for mathe¬ 
matical verification of software only work 
on small programs and make approxima¬ 
tions that can hide serious errors. ’ ’ Parnas 
does not expect major improvements in 
these tools in the SDI time frame. 


Our job is to reduce the errors. 

What makes the SDI software complex is that it deals with a very large net¬ 
worked real-time, time-critical application whose “threat” environment can only 
be guessed. Estimates of its size range from 10 million to 30 million lines of 
executable source code. Most other systems that work in a distributed real¬ 
time environment like SDI are very much smaller—under a million lines of code. 
Only a few systems so far are larger than that. For example, the safety and con¬ 
trol system of a nuclear reactor is about one million lines, as is AT&T’s No. 5 
Electronic Switching System. The Safeguard antiballistic missile software was 
over two million lines. We simply do not have much experience with systems in 
the range of millions of lines of code. 

In addition to the control software, the sizes of the databases on which such 
systems work are huge, varying from 10 million bytes to several trillion bytes. 
Moreover, effective development of such a system requires a software support 
system (tools, analyzers, dynamic simulators, etc.). 

The Fletcher report, the 1983 presidential study that laid the groundwork for 
the Strategic Defense Initiative, estimates that the system should be capable of 
100 million operations per second. It should be reliable enough to survive 
autonomously for at least 10 years without massive failures. It should have a 
mean time between failures or crashes of two years. 

Hardware reliability. Wing Toy of AT&T Bell Laboratories has shown (in a 
soon-to-be-published paper) that a reconfigurable triple modular redundant 321 
(TMR 321) system—a system with three active processors, two of which can 
fail without impairing functionality—has a mean time to failure of 208 years. 

The TMR 321 system has three processors that perform the same computation. 
If one processor fails (detected by Its disagreement with the others), it is taken 
out of the system for repair. If then one of the two active processors fails, the 
good processor continues to compute with extensive self-checking. His projec¬ 
tion is based on a failure rate per module of less than 10' 4 (roughly one failure 
per year), a repair rate per module of 0.125 (roughly eight hours per repair), and 
a probability of zero for expected recovery from any fault. These figures imply 
that hardware of this sort is reliable enough for the SDI mission. 

Performance. The 100 million operations per second recommended by the 
Fletcher report could be met by supercomputers like the Cray X-MP. However, 
this capability is now available only for a ground-based environment. Moreover, 
space-borne computers generally run one order of magnitude slower than 
ground-based computers because of environmental considerations. To sustain 
the required performance, we have to use either multiple computers, running at 
a slower rate, or we have to design much faster machines, which advances in 
hardware technology will make possible. 

Communications degradation. Before engagement, with communications 
lines clear, the network would have a high communications bandwidth on the 
order of 10 million bits per second, according to the estimate of the Fletcher 
report. Allowing for redundancy to offset noise and enhance security, this 
bandwidth might be reduced by several orders of magnitude. Then during battle 
this bandwidth might shrink still further—perhaps to zero—meaning the failure 
of communications between different entities of the distributed system. 

In effect, the SDI network would move from a highly cooperative complex 
before battle to a loosely coupled data-sharing network early in the engage- 
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Product verification by exhaustive case 
analysis is feasible only when the number 
of cases is small or the product has a 
highly repetitive structure, he went on. 
“Software has a huge number of states 
and no regularity.” 

Thorough testing is not possible 
because a large, complex software system 
has too many input conditions and goes 


C. V. Ramamoorthy 
University of California, Berkeley 


through too many internal states, he said. 

Less critical systems than SDI seem to 
go into operational use at about the 95 
percent reliability level, that is, 5 percent 
of the total errors still remain. 10 The re¬ 
maining errors are worked out during a 
“maintenance” phase that may last for 
months or years. 

Presumably SDI would be deployed 


with some remaining errors and some of 
them would be found and fixed in the 
course of in-line, or simulated, opera¬ 
tional testing. Unfortunately, full opera¬ 
tional use involves a nuclear exchange. 
“We can’t fix it after it fails for the first 
time,” Parnas told the Compcon au¬ 
dience, “because we are all going to be 
thinking about other things if we are 
thinking at all.” 

The battle management 
computing problem 

For the very high level of reliability required for 
a strategic defense system, the central question 
is how to design this system such that errors are 
first minimized and then tolerated. 

—Eastport Study Group 

The SDIO Panel on Computing in Sup¬ 
port of Battle Management, also known 
as the Eastport Study Group, accepted 
the reality that ‘ ‘all systems of useful com¬ 
plexity contain software errors.” 5 The 
question it addressed in its 30,000-word 
report was what to do about it. The 
answers range over system architecture, 
exploratory development, abundant com¬ 
puting power, testing, fault tolerance, and 
software research. 

Architecture. There is a natural tenden¬ 
cy to think of SDI as one vast system—10 
million lines of code, thousands of sen¬ 
sors, hundreds of weapons, and so on. 
Such a system would be fragile and 
unreliable. There is a further tendency to 
concentrate on the various weapon 
possibilities, then on the means to sense 
the targets, before giving much consider¬ 
ation to the computers, communications, 
and software that manage the whole. 

“If the United States can not build 
computing systems and battle manage¬ 
ment software to control the sensors and 
weapons, then the sensor and weapon 
characteristics and placement are purely 
academic,” the panel pointed out. In its 
judgment the Phase 1 contractor studies 
of system architecture that have already 
been made focused too much on sensors 
and weapons and not enough on issues of 
software complexity and testability. 

The panel recommended that SDIO de¬ 
velop an open and distributed architec¬ 
ture. “An army can not and need not 
coordinate each action of every soldier 
through the commander-in-chief,” it 
pointed out. “Instead, responsibility and 
authority are delegated in the chain of 


' ment, and ultimately perhaps to a set of autonomous nodes, each with suffi¬ 
cient computing power to carry out its functions in isolation from the network. 
The software capable of reconfiguring the system as it moves through this se¬ 
quence could be extremely complex, but there is a good prospect for success 
i through research and advances in technology. 

Software errors. Studies of the errors experienced in large real-time systems 
reveal that about 80 percent result from two major sources: requirements and 
design errors, and a combination of unknown causes and operator errors. 

The first category generally results from the failure to state the system re¬ 
quirements explicitly—ambiguity, incompleteness, faulty assumptions, etc. 

! Also, since these large systems take many years to develop, constant changes 
in the application, the requirements, and the technology take place. These 
changes create auxiliary changes, leading to the ripple effect and possibly 
I culminating in additional errors. 

Unanticipated failures can occur if the problem environment is not fully 
understood. These difficulties can be overcome by new techniques like rapid 
prototyping—where the customer can “see” the behavior of the system before 
it is fully implemented—or by customer participation in the development of the 
system. 

In the SDI application, while we cannot always predict the exact nature of the 
battle action, we can at least reduce the number of unanticipated failures by 
carefully examining the assumptions made between the customer, the devel¬ 
oper, the maintainer, and the user. Users should know how the system will 
behave at all times in all modes. Formal methods and knowledge-based sys¬ 
tems could be used to support the real-time understanding of the system’s 
! behavior so that the operators would not be confused. With better understand¬ 
ing they could react faster and more accurately. 

Reducing software errors. While all errors cannot be eliminated, their inci¬ 
dence can be reduced by proper development methodologies, intensive testing, 
formal validation techniques, and fault-tolerant designs. Software development 
methodologies are disciplined ways of generating high-quality software with 
greatly reduced effort. The main emphasis of these are in decomposing the 
large system into many easily manageable components and producing soft¬ 
ware with computer-aided tools and analysis procedures. Results in software 
reliability theory attempt to predict the approximate number of errors in a pro¬ 
gram and the amount of effort needed to reduce them. Fault-tolerant design 
techniques reduce the impact of errors by generating correct results using an 
alternate version of the program if the active version produces an erroneous 
answer. In one major technique (multiversion development), two or more teams 
of programmers develop software from the same set of requirements and each 
version is tested intensively against the others to reduce common-mode errors. 
The assumption in this technique is that the probability of every team making 
the same error is very low. Since testing in the actual SDI environment is not 
possible, simulations and experiments must be conducted in environments ap¬ 
proximating the actual. 

There has been much discussion of errors in the SDI. As computer and soft¬ 
ware professionals, it is our job to reduce the frequency of their occurrence. 
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command. Similarly, a strategic defense 
system need not and should not be tightly 
coordinated.” 

To take one example, the panel made a 
preliminary analysis and simulation of the 
assignment of weapons to individual 
missiles during the boost phase under 
both a centralized and decentralized ar¬ 
chitecture. It found that the decentralized 
approach would require about 20 percent 
more shots to destroy a given number of 
missiles than a perfectly coordinated sys¬ 
tem would require. “The tradeoff is that 
perfect coordination saves a certain 
amount of hardware at the cost of in¬ 
creased software complexity and de¬ 
creased testability,” it said. 


These projects should start out relative¬ 
ly small, at about the 25-manyear level, 
the panel said. “Initially, the projects 
could work with abstractions or simulated 
approximations of the sensor and weapon 
characteristics. Each project should be 
capable of being expanded to a much 
larger scale exploratory development. As 
the prototype battle management systems 
increase in size and capability, the level of 
realism and detail in the simulations 
would be increased.” 

The prototype programs should be a 
means to assess the feasibility of a range of 
battle management software and ulti¬ 
mately should lead into good specifica¬ 
tions. Out of these projects should come 


The prototype programs should be a means to 
assess the feasibility of a range of management 
software and ultimately should lead into good 
specifications. 


Moreover, it is obvious when one stops 
to think that SDI will never be a static sys¬ 
tem. New models of weapons, sensors, 
communications links, and computers 
will appear in periodic releases. Changes 
will be made to offset enemy counter¬ 
measures. The architecture must be for¬ 
mulated as an “open system” that can 
allow the rapid insertion of unanticipated 
and modified elements, the panel said. 

The important point is that software 
problems—reliability and testability- 
must be considered in the architectural 
tradeoff studies, the Eastport Group 
stressed. 

Exploratory development. The panel 
regarded the “waterfall diagram” para¬ 
digm, “the portrayal of a software devel¬ 
opment project proceeding smoothly and 
unidirectionally from requirements speci¬ 
fication to design specification to coding, 
testing, and delivery,” as a misconception 
of the reality. “The truth is that these steps 
can, and often do, feed back into any of 
their predecessors.” 

The panel felt that the design space of 
possible architectures is “vast.” It be¬ 
lieves that there are no analytical methods 
that can assess the feasibility of each ar¬ 
chitecture. To probe these mysteries, it 
recommended the construction of several 
prototype battle management software 
systems by different organizations. 


not only prototype software, but also 
“precise definitions of the formulation of 
the system in terms of modules and the in¬ 
terface protocols among them.” 

Computing power. The panel expects 
hardware technology to continue to in¬ 
crease computing speed and to reduce 
size, weight, and power. The issue for SDI 
is how to make effective use of this in¬ 
creasing power. In general, the panel 
recommended that this massive computer 
power be used to simplify other tasks and, 
in particular, not to make the software 
overly complex in order to compensate for 
the lack of hardware power. 

In the area of software development, 
for example, the panel believes that 
greater computing power—even super¬ 
computers or their future equivalents— 
may allow developers to create new tools 
and techniques. “For example, it may be 
possible to build much higher quality 
debugging environments or to support 
much more detailed semantic checkers 
than are currently available,” it observed. 
It may be feasible to exploit the real-time 
animation of algorithms. 

Testing. Confidence in the ability of 
SDI to work is “a critical technical 
point,” the panel noted. It regards several 
approaches to the testing problem as 
promising: 


(1) “Develop system architectures in 
which there is relatively little dependence 
on coordination or in which the coordina¬ 
tion information is used only if available. 
These architectures are relatively easier to 
test in parts.” 

(2) “Use simulation extensively, using 
very high-speed and/or highly concurrent 
programmable computers that would 
allow the operational code and algorithms 
to be tested under very large numbers of 
battle variations.” 

(3) Test components and the system in 
the actual operating environment with 
simulated data going to and from the sen¬ 
sor and weapon platforms, since real 
operation is not possible. 

(4) Continue such testing over the life 
time of the deployed system. 

“Hierarchically organized systems lend 
themselves readily to this type of testing,” 
the panel said. Moreover, partitionable 
systems reduce the vast number of states 
to be tested. In this connection the ap¬ 
plication of greater computing power to 
testing would make it possible to test more 
states than otherwise. 

Fault tolerance. The design of hard¬ 
ware to accommodate or to recover from 
faults is an established field, but the 
design of fault-tolerant software is less ad¬ 
vanced. “SDIO should place considerable 
emphasis on the invention, refinement, or 
evaluation of software design techniques 
that would allow computing functions to 
be performed usefully despite hardware 
faults or software errors,” the panel 
recommended. 

One such technique sets several in¬ 
dependent programming teams to writing 
a program to the same specification. Then 
the programs are run together with a deci¬ 
sion procedure comparing their outputs. 
The panel urged larger experiments than 
have been previously feasible to evaluate 
this technique, but it warned of the 
possibility of highly correlated program¬ 
mer errors in the different programs. 

Other techniques include watchdog 
processes, data structure audits, recovery 
blocks, runtime checking, and decisions 
based on probability distributions. Run¬ 
time checking, such as placing bounds on 
variables, is already used, but could be ex¬ 
tended further, the panel believes. Basing 
a decision on a probability distribution 
limits the degree to which a single fault 
can propagate. Critical data would be 
represented not by a single value but by a 
probability density function. 
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Software research. In addition to 
research in the application of massive 
computing power to software devel¬ 
opment, to further investigation of testing 
methods and tools, and to more work in 
reliability and fault tolerance, the panel 
outlined half a dozen other areas for 
research: 

(1) Mathematical proof techniques. 
While formal verification methods are 
limited and advances are likely to come 
slowly, it is possible that they can be ap¬ 
plied to at least some small modules that 
are critically important. 

(2) Specification languages. In one 
class of specification language, as suc¬ 
cessive levels of detail are added, the pro¬ 
grammer has strong assurance that the 
semantics of the more detailed representa¬ 
tion match those of the previous iteration. 
Another class, the executable specifica¬ 
tion language, forces the specifier to be 
precise and to avoid ambiguity, thus 
reducing errors. 

(3) Parallel, concurrent, or distributed 
computing. More systems with these ca¬ 
pabilities are becoming available, but the 
ability to exploit them lags. ‘ ‘SDIO should 
establish centers for studying algorithmic, 
compilation, and operating-systems issues 
in the context of programmable concur¬ 
rent computer systems with the potential 
of having fairly general application do¬ 
mains,” the panel recommended. 

(4) Development teams. “The advent 
of networks of computer workstations, 
precise specification languages, and 
other components of advanced software 
development, creates the possibility of 
structuring software development teams 
in entirely new ways,” the panel ob¬ 
served. It suggests experimenting with 
radically structured software devel¬ 
opment teams, as well as conducting an 
historical study of past large military 
software projects. 

(5) Software environments. High-speed 
tool-rich environments seem to create a 
style of program development in which 
programmers work in new and more ef¬ 
fective ways. These environments enable a 
programmer, for example, to tear a pro¬ 
gram apart and put it back together in a 
new structure with less effort than older 
ways. Study is needed to determine how 
programming style and more powerful en¬ 
vironments can best be exploited. 

(6) Maintenance. The panel expects a 
“substantial software maintenance 
effort,” but noted that there has been lit¬ 
tle research on tools for modifying soft¬ 


ware systems. It proposes, for example, 
that methods be developed “to determine 
and monitor the modules of code that 
reflect each system requirement, easing 
the job of accommodating a change to 
that requirement even if the affected code 
is dispersed rather than isolated.” 


There will be errors. 

Those who think that software designs will 
become easy, and that errors will disappear, 
have not attacked substantial problems. 

—David L. Parnas 

The whole history of large, complex 
software development indicates that 
errors cannot be completely eliminated. 
The Eastport Study Group has done a 
brilliant job of analyzing the problem and 
recommending ways to minimize and 
tolerate errors. At this time, before the 
system architecture has been defined, 
before the research has been done, and 
before the software development organi¬ 
zation has been structured, we cannot 
know how well the Study Group’s 
recommendations will be implemented. 

If the software effort was carried out as 
well as the efforts previously cited, there 
would be at least 0.5 errors per thousand 
delivered source instructions at the time of 
deployment. If the terminal phase soft¬ 
ware were to consist of about 800,000 
instructions, as the real-time Safeguard 
software did, and if the boost and 
midcourse software were comparable, the 
three would amount to about 2.4 million 
instructions. That much software would 
have about 1200 errors at the time it 
became operational. 

It takes a very effective organization to 
get errors down to that level. The Eastport 
Group obviously believes that the SDIO 
software effort must not only take advan¬ 
tage of the best currently known software 
practices but must learn to use new tech¬ 
niques that SDIO-sponsored research will 
develop. 

Unfortunately, the group “finds it a bit 
troublesome to be discussing whether 
radical advancements in software 
technology would enhance the quality of a 
new defense system, when we are aware 
that many of the DoD’s biggest software 
development contractors are presently 
literally decades behind the state of the 
art.” 

Consequently, the group devoted a 
chapter of its report to program manage¬ 
ment, offering a number of recommenda¬ 
tions designed to get this area up to speed. 


D espite the best efforts of all 
concerned, I conclude that there 
will be errors and the shield will 
leak—perhaps only a few warheads, but 
leaks nonetheless. That leads us back to 
the original purpose of the Strategic 
Defense Initiative. If it is to render nuclear 
weapons “impotent and obsolete,” as 
President Reagan stated in his March 1983 
speech inaugurating the concept, then 
these weapons will still be very much a 
potent threat. If it is to provide a partial 
defense, protecting the retaliatory missile 
silos, assuring the survival of part of the 
population, and avoiding a worst-case 
nuclear winter, SDI may accomplish this 
despite some errors. 

But the debate on nuclear strategy has 
been raging in defense circles for 40 years 
now and it is beyond the scope of this arti¬ 
cle to pursue the strategic implications. □ 
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The Computer Science Board’s Survey on the 
Production and Employment of PhDs and Faculty 
in Computer Science and Engineering: 


The 1984-85 Taulbee 
Survey 

David Gries, Cornell University 


T his report describes the results of a survey completed in 
June 1986 by 103 departments (95 US and 8 Canadian) 
on the production and employment of PhDs and faculty 
of PhD-granting computer science/engineering departments in 
the United States and Canada during the academic year 
1984-85.* Some highlights from the survey are 
• The 103 departments produced 326 PhDs. Of these, 167 
were US citizens, 22 Canadian, and 122 foreign (the citizenship 
of 15 was unreported). Of the 326, 159 went to academia, 105 to 
industry, 13 to the government, and 32 overseas; 6 were self- 
employed. 

• The departments expect to produce 498 PhDs next year. 
(Judging from past experience, this is optimistic; under 400 is 
more likely. Nevertheless, the increase may be over 20 percent.) 

• In the past year 755 graduate students in 92 departments 
passed their qualifying exams. 

• The 103 departments had 1741 faculty members: 678 assis¬ 
tant, 466 associate, and 597 full professors. It’s a very young 
discipline. The eight Canadian departments reported having 179 
faculty members; the 95 US departments, 1562. 

• The departments reported hiring 204 regular faculty and 
losing 153 (to retirement, death, other universities, and 
nonacademic positions); thus there was a growth of 51, or 2.5 
percent. 

• The 103 departments want to grow from 1741 faculty 
members to 2527 by 1990-91, an increase of 45 percent in five 
years, at an average rate of about 1.5 per department per year. 

Some methodological comments. Questionnaires were sent to 
109 PhD-granting computer science/engineering departments. 
Electrical engineering departments were not considered, but 
those that have “Computer” in their title were (e.g., the depart¬ 
ment at MIT). The decision to include computer engineering as 
well as computer science departments is new, and other depart¬ 
ments that want to be included in the next survey should contact 
the author. 

As with most surveys, a small part of the data in the survey was 
not filled in or obviously was incorrectly entered. I took the 


This is a revision by Joyce Friedman and the author of a survey conducted by Orrin 
E. Taulbee of the University of Pittsburgh, who conducted these surveys for the 
Computer Science Board yearly from the early 1970’s through 1984. 


liberty to adjust some figures and estimate a few others—for 
example, in a few cases, with 100 or 101 out of 103 departments 
reporting a figure in a field, I estimated that field for the other 
two. My goal was to make this report consistent, clear, and sim¬ 
ple, without modifying the overall results in any way. 

Of the 109 departments contacted, 103 responded to the 
survey. (The six departments that did not participate are George 
Washington, Kentucky, Manitoba, Stevens Institute of 
Technology, Texas Christian, and University of California at 
Santa Cruz.) This means that the figures in this report should be 
quite accurate for the field as a whole. 

In some places I analyze the data for the higher ranked depart¬ 
ments as compared to the lower ranked and unranked ones, 
using for ranking the 1980 survey done under the auspices of the 
National Research Council. 1 This survey is now six years old, and 
many changes have occurred in computer science since then (e.g., 
the emergence of over 50 more PhD-granting departments); 
nevertheless, it does provide for some useful comparisons. I took 
the liberty to place the largest two Canadian universities 
somewhere in the top 30, since Canadian universities were not 
surveyed in reference 1, nor Purdue either, which did not par¬ 
ticipate in the ranking. 

Data on students 

The 103 departments produced 326 PhDs and expect to pro¬ 
duce 498 next year. This expectation is very optimistic, and well 
under 400 in 1986 is more likely. With 755 graduates in 92 depart¬ 
ments passing their qualifying exams, if 60 percent of them 
actually write a PhD thesis, in 2-3 years 450 of them will receive a 
PhD. 

Sex and minority status of the PhDs. Table 1 gives a 
breakdown of PhDs according to sex and minority status. 

Citizenship of the PhDs. Of the PhDs produced, 167 were 
reported to have US citizenship, 22 Canadian citizenship, and 


*Sixty-six departments reported on an academic-year basis and 24 on a 1985 
calendar-year basis. Thirteen neglected to indicate the system they were using. 
Typically, departments report year after year on the same basis, so the difference has 
np effect when viewing changes in the Taulbee-survey data from year to year. 
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Table I. 


White, not of Hispanic origin 
Black, not of Hispanic origin 
Hispanic 

Other or unrepoited 


Outside academia 


Outside US, Can. 
Unaccounted for 


Total _ 

125 Self-employed 6 

Industry 106 

Government 13 

159 PhD CS dept. 114 

Non-PhD CS dept. 32 

Other dept. 13 

10 


Depts. that Depts. th 
produced produce 
under 3.2 3.2 or m< 


PhDs, ’85 
(aver, per dept.) 
Expected, '86 
Expected 1-year growth 
No. students passing 


( .9) 261 (7.9) 

174 (2.4) 324 (9.8) 

109 (167%) 63 (24ft) 


157 ( 1.9) 169 (8.5) 

254 ( 3.1) 244 (12.2) 
97 (62ft) 75 (44ft) 


Table 4. 

Non-PhD degrees, 

PhD departments only Undergrad. 85 Undergrad. 86 Masters 85 Masters 86 

No. degrees 10,422 10,363 2889 3233 

No. depts. responding 96 95 101 101 

Average per department 109 109 29 32 



Total 3506 1558 1177 2416 1018 675 

Depts. responding 100 87 97 93 97 39 

Average per dept.35 18 12 26_10 17 


Tablet.__________ 

New PhD students No. depts. Total Average 

by dept, rank _ 

Ranked 1-12 12 349 29 

Ranked 13-24 12 219 18 

Ranked 25-36 12 144 12 

The rest 62 465 8 


122 citizenship of another country (15 were unreported). Thus 
about 60 percent were US-Canadian and 40 percent foreign. 

Employment of the PhDs. As shown in Table 2, 39 percent of 
the PhDs produced took positions in the United States or 
Canada outside academia, 50 percent took faculty positions in 
the United States or Canada, and 10 percent took positions in 
other countries. 

PhD production and its growth. One of the questions the field 
has is how fast PhD production will increase. As shown in Table 
3, a one-year growth of 172 (50 percent) is expected. 

However, 29 departments produced no PhDs this year; 24, 1 
PhD; 10, 2 PhDs; and 7, 3 PhDs. That is, 70 departments pro¬ 
duced less than the average and 33 more than the average. One 
might expect the growth patterns of these departments to differ 
from that of the major producers. To that end, we show the data 
for the two groups in the middle columns of Table 3. One-third 
of the departments produced 80 percent of the PhDs—almost 
eight per department. As one might guess, the over-average 
group expects to increase its PhD production only half as much 
(by 63) as the under-average group, which expects to raise its out¬ 
put in one year by 109, or 167 percent. 

In an effort to find different expected-growth patterns, the 
data was analyzed for the group of departments ranked 1 to 20 
and for the group ranked 21 and below (see the rightmost 
columns of Table 3). The cutoff was made at 20 because the top 
19 produce less than half and top 20 more than half the PhDs. 
The same kind of figures were produced for the 21 largest depart¬ 
ments as opposed to the rest; the figures are not shown because 
they are quite similar to those based on rankings. 

Undergraduate and masters degrees. Little change is expected 
in 1986 in terms of undergraduate degrees, but masters-degree 
production is expected to rise 12 percent. In Table 4 note that 
many universities have undergraduate and/or masters programs 
but do not award the PhD, so this data says little about the field 
of computer science as a whole. 

New graduate students in Fall 1985. In Table 5 the column 
heading “PhD program” stands for the number of new graduate 
students in PhD programs, regardless of whether they intend to 
earn a masters degree first. 

The data for part-time masters students need some expla¬ 
nation. Thirty-six departments did not respond or had zero 
part-timers, and 61 departments had five or fewer. For these de¬ 
partments the part-time masters program may be inconsequen¬ 
tial—perhaps just a small employee program of the university. 
On the other hand, the largest part-time masters programs had 
47, 100, and 150 new students! The last column gives figures 
only for departments with between six and 50 new part-time 
masters students. 

Table 6 gives the number of new PhD students in departments, 
grouped by rank. 

Faculty 

In Table 7 all figures are in terms of “full -time equivalents.” 
Thus, if a department had two half-time joint appointments, 
these counted as one. All 103 departments reported this informa- 
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Hiring for 1985-86. Ninety-six departments reported hiring 
204 new faculty. Salaries were reported for new PhDs hired for 
Fall 1985 by 52 departments. Table 8 gives the salary infor¬ 
mation, but for US universities only. Canadian salaries are on a 
12-month scale, the Canadian and US dollars are different, and 
there are differences in the amount of consulting that typically 
can be performed. Finally, since only three Canadian universities 
reported these figures and they had an effect on the results, it 
seemed better to omit them. 

More information is included in Table 9, which gives the num¬ 
ber of salaries paid in each $1000 range ( numbers are rounded 
and presented in thousands of dollars). 

The departments reported hiring only 18 faculty with PhDs 
earned in 1980 or later in a field other than computer science/en¬ 
gineering. The fields were: computational linguistics, business 
administration, applied math (five), mechanical engineering, 
electrical engineering (six), linguistics, mathematical physics, and 
physics (two). 

Faculty salaries. Table 10 summarizes 9-month faculty salaries 
during the 1984-85 academic year. Each department reported the 
minimum, mean, and maximum salary of assistant, associate, 
and full professors and the number of faculty in each rank. For 
minimum salaries (and for maximum salaries), the table shows 
the minimum, average, and maximum. Finally, the average is 
given over all salaries in each faculty rank—this is not the average 
of the means, but the true average. Canadian departments are 
not included in this summary. 

Five-year estimates of department growth. The departments 
were asked to estimate their faculty sizes through 1990-91, given 
an adequate supply of candidates (the lack of candidates has 
been a problem in the past). Some of the figures had to be trans¬ 
lated for a few departments that reported the incremental num¬ 
ber of positions available each year instead of the total number of 
faculty. Also, there is a discrepancy of 79 in the total number of 
faculty reported in 1985-86 (1820) and total reported elsewhere in 
the questionnaire (1741). 

According to the survey, the 103 departments would like to 
grow by 46 percent in the next five years (Table 11). To do this 
with new computer science PhDs alone would require about 200 
new PhDs per year (not counting for losses to industry, etc.). 

Is the growth expected in the high-ranked departments? The 
lower-ranked? The large ones? The small ones? Table 12 in¬ 
dicates that essentially the same absolute growth is expected in all 
categories. 

Faculty losses. The field lost only 16 people through death or 
retirement, which is less than 1 percent. This, together with the 
distribution of the faculty in the three ranks, underscores the ex¬ 
treme youth of the field. 

Of the 180 faculty that left, at least 74 left for other teaching 
positions and 106 left academia (Table 13). 
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statistics 


1 Depts. 

Top 25 Depts. 

Other 78 Depts. 

Total 

Average 

Total 

Average 

Total Average 

Tenure-track faculty 

1741 

17.0 

612 

24.5 

1129 14.4 

Assistant prof. 

678 

6.6 

248 

9.9 

430 5.5 

Associate prof. 

466 

4.6 

131 

5.2 

335 4.4 

Full prof. 

597 

5.8 

233 

9.4 

364 4.7 

Nonteaching research fac. 

96 

.9 

50 

2.0 

46 .6 

Postdocs 

68 

.7 

37 

1.5 

31 .4 

Non-tenure-track teachers 

305 

3.0 

66 

2.7 

239 3.1 

Other faculty (e.g., visitors) 

191 

1.9 

67 

2.7 

124 1.6 


Table 8. _ 

New PhD salaries 
No. depts. reporting 

Average (of the 
averages) 

Maximum 


All depts. Top 25 depts. Other 76 depts. 

52 20 32 

$30,000 $34,000 $30,000 

$36,668 $37,240 $36,310 

$40,650 $40,650 $40,000 


Table 9. 

New PhD salaries 30 31 32 33 34 35 36 37 38 39 40 41 

No. paid_1 0 2 2 2 2 10 11 II 5 5 1 


Table 10. 


Faculty Reported minimums Average over Reported maximums 

rank Number Min Mean Max all salaries Min Mean Max 

Assistant 609 26500 34888 40800 37455 32814 39434 51900 

Associate 375 28250 39446 48000 43115 34900 45619 62150 

Full_470 31572 46141 72200 56952 40000 64833 110000 


Table 11. 

Faculty growth 85-86 86-87 87-88 88-89 89-90 90-91 5-year increase 

Faculty size 1820 2064 2248 2403 2528 2649 829 (46%) 

Average size 18 20 22 23 25 26 8 


Table 12. 

Average desired 
5-year growth 
Per department 
Average dept, size 85-86 
Average dept, size 90-91 
Average 5-year increase 
Percent growth (proj.) 


By rank 

1-12 12-24 24-36 Rest 

29 22 18 15 

38 31 28 23 

9 9 10 8 

31% 40% 55% 53% 


By department size 
1-9 10-19 20-29 30-39 4042 

7 14 23 34 41 

14 21 32 45 61 

7 7 9 11 20 

50% 50% 39% 32% 50% 


Table 13. 


Died or retired 

Were visitors, returned to employer 
Teaching elsewhere 
Left for nonacademic position 
Returned to grad school 
Other 
Total 


With PhD Without PhD 


15 

72 

51 


161 


Total 


21 

74 

62 


180 
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Sponsored by the Computer Society of the IEEE 

D atabase Engineering is concerned with the role of data and knowledge about data in the design, development, 
management, and utilization of information aspects of databases, knowledge bases, and data management in general. 
The purpose of this conference is to continue to provide a forum for the sharing of experience, practice, and theory 
of automated data and knowledge management from an engineering point-of-view. The effectiveness and productivity 
of future information systems will depend critically on improvements in their design, organization, and management. 


GENERAL SESSIONS: February 3-5, 1987 


■ Access Methods 

■ Distributed Operating Systems 
and Distributed Databases 

■ Database Design and 
Implementation 

■ Performance Evaluation 

■ Relationship Between Data 
Engineering and Software 
Engineering 

■ Architectural Support for 
Database Management 

■ Evaluating Recursive Queries 


■ File Structures 

■ Parallel Processing in Database 
Systems 

■ Object Based Systems 

■ Performance in Distributed 
Systems 

■ Statistical Databases 

■ Symbolic Processing 

■ Improving Doncurrency in 
Distributed Systems 

■ Fault Tolerance and Correctness 

■ Knowledge Representations 


■ Resiliency in Distributed Systems 

■ Fault Tolerant Storage Systems 

■ Data Modeling 

■ Experiences in Data Engineering I 

■ Database Security Issues 

■ Historical Databases 

■ Experiences in Data Engineering II 

■ Engineering and Information 
Manufacturing Systems 

■ Extending the Relational Model 

■ CAD/CAM Systems 

■ Query Processing 


PLENARY SESSIONS 

The Adventures of a Real-World Database Machine Company, P. Neches 
Uncertain Data Management, L. Zadeh 

Personal Database for Personal Computers: Intelligent & Flexible Databases for Individuals, J. Kaplan 
What Have We Learned?, B. Wah 


TUTORIALS: February 2, 5 and G, 1987 

Monday 

9:00 am-5:00 pm: Computers for Artificial Intelligence Processing, Benjamin Wah 

9:00 am-5:00 pm: Real Data Engineering, Tom Gilb 

9:00 am-12 noon: An Introduction To NIAM Modeling, Paul S. Thompson 

9:00 am-12 noon: Reference Architecture for Distributed Database Management Systems, Saeed Rahimi 
1:30 pm-4:30 pm: Distributed Database Management Principles, Saeed Rahimi 
6:30 pm-9:30 pm: Automated Support Environments for Database Design, David Reiner 
6:30 pm-9:30 pm: Heterogeneous Distributed Databases: Issues in Integration, Amit P. Sheth 

Thursday 

6:30 pm-9:30 pm: Introduction to Object Oriented Concepts: Smalltalk and Database, James Diederich and Jack Milton 

Friday 

9:00 am-12 noon: Logic Programming, Expert Systems and Databases, Steve Hardy 
9:00 am-5:00 pm: Database Application Development Tools, S. Bing Yao 

For a complete Advance Program, contact: 


Data Engineering Conference 

c/o Computer Society of the IEEE 
1730 Massachusetts Ave., N.W. 
Washington, DC 20036-1903 
C2021 371-0101 
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DATA ENGINEERING 1 

HOTEL RESERVATION FORM 

Hotel Address: Pacifica Hotel and Conference Center 

6161 Centinela Avenue 
Culver City, CA 90230-6306 
Tel.: (213) 649-1776 
1-800-421-1448 or 1-800-262-1574 
(California only) 

The hotel is located 3 miles north of Los 
Angeles International Airport and provides 
24-hour complimentary limousine service 
to and from Los Angeles International 
Airport. The bus runs every half-hour. Use 
the telephone in the baggage claim area to 
call the hotel for pickup. 


Credit Cards: All major credit cards accepted 

To be able to confirm the reservation, we must receive the 
coupon by January 19, 1987. To guarantee reservations, 
we also must receive one night deposit, plus 8% occupancy 


Reservations made after January 19, 1987 are subject to 
space availability. Check-in time is 3:00 p.m. Check-out time 
is 12:00 noon. 

Cancellations must be received by hotel at least 48 hours 
prior to date of arrival. 


DATA ENGINEERING 
REGISTRATION FORM 

FEBRUARY 2-6, 1987 

Complete and return this form with your check made payable 
to DATA ENGINEERING CONFERENCE to: 

Data Engineering Conference 
c/o Computer Society of the IEEE 
1730 Massachusetts Ave., N.W. 

Washington, DC 20036-1903 

Advance Registration 
Prior to 1/9/87 

Member Non-Member Student/Retired 
$240 $35 


Conference $190 

Half Day Tutorial Fee 
Full Tutorial Fee 


110 


Conference $230 

Half Day Tutorial Fee 110 
Full Tutorial Fee 200 


200 

Late Registration 
After 1/9/87 
Member Non-Member Student/Retired 
$290 


135 

250 
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pm tutorial on the same day. 
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BOOK REVIEWS 


Computer Work Stations— Herman 
Holtz (Chapman and Hall, New York, 
1985, 302 pp„ $24.50) 

This book is not recommended to the 
readers of Computer because its descrip¬ 
tion of computers, operating systems, 
and local area networks has glaring er¬ 
rors—and discusses outdated tech¬ 
nology. Furthermore, the author often 
deviates far from his stated topic and 
has an exasperatingly verbose writing 
style. 

In the Preface the author states two 
purposes in publishing this book: first to 
aid managers in the understanding of 
computer work station configurations, 
differences between configurations, the 
criteria in analyzing work station needs, 
and methods for arriving at a sensible 
decision in satisfying those needs; and 
second, to equip the manager to discuss 
work stations with the technical experts 
and understand the claims and specifica¬ 
tions in the literature supplied by those 
experts. Mr. Holtz perhaps partially suc¬ 
ceeds in his first purpose, but the man¬ 
ager is in for a rude awakening when he 
or she attempts to converse with a tech¬ 
nical expert. Mr. Holtz has, at best, a 
tenuous grasp on technology. 

In order to give the reader the flavor 
of this book (and to justify the com¬ 
ments above), I feel compelled to quote 
some of the more offensive text. 

To illustrate an incompatible inter¬ 
face, Mr. Holtz makes the analogy of 
using a “ . . . Volkswagon to draw an 
industrial trailer over the highway; the 
mismatch is quite obvious” (p. 36). And 
in the next paragraph he tries to state 
the electrical properties of an incompat¬ 
ible interface: “In a typical mismatch, 


one device will act as a ‘load’ or drag on 
the other, so that neither device will 
function well.” In this reviewer’s experi¬ 
ence, incompatible interface connectors 
won’t mate, and if they do, the con¬ 
nected devices simply won’t work 
(though they may “smoke.”) 

The author does not seem to under¬ 
stand communications very well either. 
He states, twice, that the matters of 
transmission speed and communications 
protocol are “highly technical” (e.g., p. 
86), but later does tell the reader that 
“There are a large number of protocols 
in use—RS-232, RS-422, and HASP, to 
name just a few in use” (p. 127). This 
reviewer thinks an understanding of 
such basic network principles as trans¬ 
mission speed and protocol is vital to 
management of network performance 
and cost. The manager must know the 
available speeds and protocols to set the 
budget, and properly staff a project. 

While discussing LANs (p. 236), the 
author says: “Probably RS-232 is the 
most popular protocol found among 
that class, although it is far from being a 
dominant one, and others in fairly com¬ 
mon use are X.25 and Ethernet.” This 
statement confuses hardware, wide area, 
and local area network protocols. More¬ 
over, Mr. Holtz does not seem to under¬ 
stand the meaning of LAN for he states 
(p. 90): “Some LANs are obviously in¬ 
tended for large-scale use, offering 
capabilities for thousands of stations 
and many miles of interstation 
distances.” He also includes modems in 
his illustrations of LAN configurations 
(e.g., pp. 20-21). 

One problem evident throughout the 
book is that the author doesn’t under¬ 
stand the difference between multitask¬ 


Recently published books and new periodicals may be submitted for 
review to the book reviews editor: 

Francis P. Mathur, Mathematics Department, California State Polytechnic 
University, 3801 West Temple Avenue, Pomona, CA 91768, (714) 598-4421. 

Note: Publications reviewed in this section are not available from the 
IEEE Computer Society; they must be ordered directly from the publisher. 
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ing and multiuser systems, which he 
ascribes to the computer industry’s lack 
of standard terms. He mentions this 
many times throughout the book. For 
example, when discussing the distinction 
among the “functional terms” multi¬ 
user, multitasking, multiprogramming, 
and multiprocessing (p. 103), he states, 
“But the differences lie more in the area 
of semantics than in functional reali¬ 
ties—than in real capabilities, to be 
blunt.” On the next page he states that a 
significant factor in limiting multitasking 
in the personal computer is that of hav¬ 
ing just one CPU. And on the following 
page, in discussing the “software 
factor” in multitasking, he cites win¬ 
dowing and integrated software as “en¬ 
abling more multitasking.” For Mr. 
Holtz’s benefit, multitasking is the abili¬ 
ty to maintain more than one active pro¬ 
gram simultaneously: When the current¬ 
ly executing program goes into a wait 
state (e.g., waiting for data from a disk, 
or waiting for a user response), another 
active program will be run without oper¬ 
ator intervention; a multiuser system re¬ 
quires multitasking, and allows more 
than one user to run programs (although 
most multiuser systems also include 
passwords and some form of accounting 
for computer time and disk storage and 
often limit an individual user’s access to 
system resources). Further, multiuser 
and multitasking are generally properties 
of the operating system, not the 
hardware. 

There are many other examples of the 
author’s lack of technical expertise. This 
reviewer is shocked and dismayed that a 
book containing so many technical er¬ 
rors could be published—especially in 
this day and age of computer literacy. 
Any reader of this book will be misin¬ 
formed and totally confused if she or he 
then attempts to staff a work station 
project or (heaven forbid!) attempts to 
purchase a system. At least Mr. Holtz 
suggests hiring technically competent 
people and consultants; but the reviewer 
wonders how the manager schooled by 
this book could establish reliable criteria 
to staff and maintain computer work 
station projects. 

Terry M. Kenney 

Consultant, ASPEC Co. 
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Database System Concepts —Henry F. 
Korth and Abraham Silberschatz 
(McGraw-Hill, New York, 1986, 546 pp„ 
$37.95) 

This book is an excellent introduction 
to database system concepts. In its fif¬ 
teen chapters it covers data abstraction; 
data models, instances, and schemes; 
data independence; data definition lan¬ 
guage; data manipulation language; the 
database manager, administrator, and 
users; and overall database system struc¬ 
ture. There are individual chapters on 
the four major data models: entity- 
relationship, relational, network, and 
hierarchical. There is also a chapter on 
the theory of relational database design, 
with normalization and data indepen¬ 
dence covered in detail. 

In the chapters on file and system 
structure, indexing and hashing, and 
query processing, the internal structure 
of database systems is explored. Crash 
recovery is the topic of Chapter 10, 
followed by chapters on such advanced 
topics as concurrency control, distrib¬ 
uted databases, and security and integri¬ 


ty. Current trends such as knowledge 
bases are discussed in the chapter on new 
database applications. The last chapter 
gives case studies on the relational, net¬ 
work, hierarchical, and microcomputer 
database system, with at least two ex¬ 
amples for each type of system. 

Each chapter has a summary of the 
important concepts and provides bibli¬ 
ographic notes. The author provides a 
bibliography for the whole text. 

This book can serve as an excellent 
text for a junior- or senior-level course 
introducing database concepts. Its wide 
spectrum of topics allows the instructor 
flexibiltiy. It can also serve as a graduate- 
level text with suitable supplementary 
material. The student should have some 
exposure to set theory, logic, and discrete 
mathematics to feel comfortable in the 
section on formal query languages. 
Mathematical maturity would be helpful 
to appreciate the section on relational 
calculus. To handle the chapters on ad¬ 
vanced topics, students should have 
some background on operating systems. 

This is one of the first books in the 
database area that is readable and inter¬ 


esting and has a broad range of topics. 
The order of presentation is both logical 
and pedagogically sound—and the book 
is sufficiently self-contained. 

Some of the strong points of this book 
are that the authors do not present too 
much of the nitty-gritty material, there 
are plenty of examples, each chapter has 
a good set of exercises, and there are a 
lot of proof-type problems in the chapter 
on database theory. 

No book is without typos. Some here 
are obvious, some not. 

I was disappointed that the authors 
did not mention database machines in 
the section on current trends. The sec¬ 
tion on knowledge databases should be 
expanded. 

To summarize, this is one of the best 
textbooks introducing database con¬ 
cepts. It presents a logical and excellent 
treatment of important topics in this 
area in both an interesting and readable 
manner. 


Grace C. N. Yeung 

California State University, Fresno 


New in 

Computer Science 

from 

Springer-Verlag 


Adaptive Signal Processing 

Theory and Applications 

S.T. Alexander 

Covers both older gradient-based and more 
modem least squares methods of adaptive sig¬ 
nal processing. The presentation is aimed at 
unifying optimal filtering, gradient-based adap¬ 
tive methods, and least squares techniques in a 
common notation and terminology to facilitate 
the learning of state-of-the-art adaptive meth¬ 
ods. Presents, for the first time, the vector 
space approach to fast least squares adaptive 

1986/179 pp/42 illus/cloth $36.00 

Texts and Monographs in Computer Science 

ISBN: 0-387-96380-4 


New 


Forthcoming in December . . . 


Algebraic Approaches to 
Program Semantics 

E.G. Manes and M.A. Arbib 

Focuses on the mathematical tools for the de¬ 
scription of the semantics of programming lan¬ 
guages. The book introduces and compares 
several different algebraic approaches to the 
semantics of both recursive programs and ab¬ 
stract data types. Ideal as a textbook for upper 
undergraduate and graduate-level students 
studying semantics. 

1986/351 pp/1 illus/cloth $54.00 

Texts and Monographs in Computer Science 

ISBN: 0-387-96324-3 


Taming the Tiger 

Software Engineering and Software 
Economics 

L.S. Levy 

Contents: Introduction. Unifying Themes. Me¬ 
taprogramming. The Cartesian Programmer 
and the Hacker. Software Engineering. 

AWK—A Prototyping Language. Software 
Economics. The Model. Transfer Pricing. 
Summing Up. 

1986/approx 245 pp./ll illus/cloth $25.00 
(tent) 




Recursive Source Coding 

A Theory for the Practice of Waveform 

G. Gabor and Z. Gyorfi 

A practical discussion of digital coding of ana 
log signals such as speech, image, and other 
biological signals. This book provides a criti¬ 
cal analysis of and a rigorous mathematical 
model for the practice of data compression 
techniques. An important sourcebook for any¬ 
one working on communication or storage of 
digitized analog signals. 

1986/approx 120 pp/13 illus/cloth $28.00 
ISBN: 0-387-96309-X 


To order, send check or money order 
(plus $1.50 for shipping) to: 
Springer-Verlag New York, Inc. 
Attn: G. Kiely S340 
175 Fifth Avenue 
New York, NY 10010 


. Springer-Verlag 

1 New York Berlin Heidelberg - 
London Paris Tokyo 


November 1986 


Reader Service Number 7 
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CALL FOR PAPERS 




11th ACM Symposium on Operating Systems Principles 


November 9-11, 1987 
Wyndham Hotel 
Austin, Texas 


The field of operating systems now adjoins many other areas of computer science, some 
of which may provide new perspectives on our field. We solicit papers in both the central 
and border areas of the operating systems domain. 

Some topics of interest include: 


Communication 
Database Systems 
Distributed Systems 
Language Issues 


Multiprocessor Systems 
Performance Evaluation 
Reliability 

Resource Management 


Security 

Supercomputers 
System Structuring 
Theoretical Issues 


Papers should be no longer than 5000 words (about 20 double-spaced pages). The 
title of the paper and the author’s name and address should appear on a cover sheet 
accompanying the paper. The author should not be identified in the paper itself. Blind 
reviewing will be done by the program comittee, assisted by outside referees. 

Please send twelve copies of your paper to: 

Prof. Alfred Spector 
Department of Computer Science 
Carnegie Mellon University 
Pittsburgh, PA 15213 


Authors of accepted papers will be expected to sign an ACM copyright release form. 
Proceedings will be distributed at the symposium and published as a special issue of 
Operating Systems Review, the SIGOPS quarterly. Papers of particular merit will appear 
in a special issue of the ACM Transactions on Computer Systems. 


Program Committee 

Ozalp Babaoglu, Cornell John Ousterhout, Berkeley 

Eric Cooper, CMU Michael Schroeder, DEC SRC 

David Gifford, MIT Alfred Spector (Chairman), CMU 

Edward Lazowska, Univ. of Washington Guy Steele, Thinking Machines 
Bruce Lindsay, IBM Almaden Norihisa Suzuki, IBM Tokyo 


Paper submission deadline: February 16, 1987 

Acceptance notification: May 11, 1987 

Deadline for camera-ready final papers: August 1,1987 
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UPDATE 


News from the IEEE-CS Committee on Public Policy 

Whither Computer Technology: Populist or Centrist? 

EgonE. Loebner, Chair, Subcommittee on Public Information Access 


One goal of the Computer Society, as 
articulated in its constitution, is “to pro¬ 
mote understanding of the influence that 
computer technology exercises on public 
welfare.” In accordance with that goal, 
the purpose the COPP Subcommittee on 
Public Information Access is to inves¬ 
tigate means by which the public sector 
may obtain options to access—inexpen¬ 
sively, quickly, and reliably—informa¬ 
tion of vital concern to private 
individuals. 

This purpose is important because the 
computer, like many of its technological 
predecessors, can be used either to 
enhance or to diminish public welfare. In 
the public sector, instruments used to 
implement public policy often co-deter- 
mine, by the nature of their use, the very 
outcome of the implementation. For ex¬ 
ample, a secret ballot vote is known to 
lead to a different result than an open 
ballot vote. The relatively high degree of 
freedom enjoyed by academicians in the 
Soviet Union is in no small measure the 
result of secret balloting still preserved 
by the powerful and influential Soviet 
Academy of Sciences. 

By supplying an understanding of how 
computers are currently used by lobby¬ 
ists, officials, and bureaucrats to in¬ 
fluence the legislative processes, this sub¬ 
committee will be able to elucidate the 
influence that computers have on a fun¬ 
damental aspect of American society and 
its well being. 

The problems the subcommittee is en¬ 
countering—and addressing—were dis¬ 
cussed some five years ago during a 
public forum, sponsored by the Com¬ 
puter Society’s Silicon Valley Chapter, 
on the impact of computers on legislative 
affairs. The November 24, 1981, forum 
held at Stanford University was mod¬ 
erated by William F. Miller, president of 
SRI and an IEEE fellow, and consisted 
of a panel of seven distinguished com¬ 
puter scientists, social scientists, and 
legislative experts. There was general 
agreement among the panelists that the 
primary beneficiaries of computer access 
to public information are lobbyists, 
bureaucrats, and legislators. A number 
of the panelists thought that neither mass 


media nor private parties could, in the 
foreseeable future, become effective 
users of databases containing legislative 
and regulatory information. They are 
unlikely to have changed their minds in 
the intervening five years. 

Throughout recorded history, emerg¬ 
ing technologies have exercised profound 
influence over the balance of power be¬ 
tween groups of people, whether whole 
nations or factions within nations. Ac¬ 
cording to one of the 1981 forum panel¬ 
ists, the exercise of political power is a 
zero sum game. If one group or faction 
gains political power, its opponents lose 
power. 

Up to now, the spectacular growth of 
mass communications media technolo¬ 
gies (that is, press, radio, and television) 
has significantly diminished the political 
power of private individuals and shifted 
the balance of power toward organiza¬ 
tions and their officers. The process by 
which the few influence the many, 
through writing, speaking, and TV ap¬ 
pearances, has been steadily intensifying 
since the dawn of the modern era. Only 
marginally interactive, the mass media 
continue to expand the power of writers, 
broadcasters, editors, officials, politi¬ 
cians, and bureaucrats, while 
diminishing and delimiting the influence 
of readers, listeners, viewers, consumers, 
and electors. 

Without reliable knowledge, there can¬ 
not be effective action. Thus, individuals 
and private parties, lacking organiza¬ 
tional resources, are increasingly 
relegated to powerless observation of 
public activities. The one bastion of 
private power, which has thus far been 
preserved in the United States, is 
telephone communication. Flowever, this 
is not necessarily so in other countries of 
the free world, where governments own 
the networks and control the trans¬ 
missions, reserving for themselves the 
right to challenge the privacy of point-to- 
point communications between parties. 

Current developments in advanced 
computer technology are opening up 
possibilities for new communication 
means that do not suffer the shortcom¬ 
ings of letter writing, opinion polls, and 


the ballot box. The COPP Subcommit¬ 
tee on Public Information Access hopes 
to carry out an intensive investigation 
into the options and opportunities for 
reversing the shift of power in our 
democratic, representative form of 
government. 

Computer Society members who are 
interested in serving on this exciting, but 
also demanding, subcommittee are in¬ 
vited to write to its chair, Egon E. 
Loebner, or to communicate with him 
via electronic mail. His addresses are 
Hewlett-Packard Laboratories, 1501 
Page Mill Rd., Palo Alto, CA 
94304-1181 and LoebnerVoHP- 
THOR@HPLABS.ARPA via csnet- 
relay.arpa, and his phone number is 
(415) 857-8787. 


SDIO official outlines “Star 
Wars” research approach 

Tom Szalkiewicz, Assistant Editor 

Unlike traditional approaches to sys¬ 
tems development, in which hardware 
precedes software development, the 
Strategic Defense Initiative Organization 
will emphasize parallel development of 
software and hardware, according to 
Colonel David Audley, the organization’s 
assistant director. The guest speaker at 
the October 1 dinner of the Los Angeles 
Chapter of the ACM, Audley also noted 
that for this project the DoD would take 
a new tack in its software procurement 
procedures. 

“Very often, we don’t know what it is 
we want to buy when we get started,” he 
said. “We have kind of a neat oppor¬ 
tunity with SDI. We don’t have a system 
to deal with for a few years. We all know 
that we have some time so that maybe 
we can do this right.” 

Audley enumerated the approach 
taken by the SDIO “to do this right”: 

• Prototyping. Audley remarked that 
when prototyping a system, researchers 
learn a lot. “This is perhaps more so 
with software. We’ll build a prototype as 
if it were a system, test it . . ., and 
perhaps put software in space.” 

• System architecture. The colonel 
made it clear that the choice of system 
architecture would depend on the results 
of the software R&D effort. “When we 
talk about system architecture we’re 
really talking about software. . . . We’re 
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Auditor’s report: 

Computer Society 1985, 1984 financial statements 


not ready for bricklayers to come in yet 
because we have lots of simulation activ¬ 
ities to do.” 

• Bugs. The assistant director pro¬ 
vided few insights into how the battle 
management software would be tested 
and debugged. “The notion of bugs and 
errors goes back to the notion of high 
quality. We prevent bugs by design. We 
don’t like to preplan removal of bugs.” 

• Software. The software research 
effort for SDI promises to be very com¬ 
plex, involving an army of researchers 
and state-of-the-art programming tech¬ 
niques. When asked how the SDI would 
coordinate this immense project, Audley 
replied: “It comes down to good systems 
engineering and good management 
practice.” 

• Complex software systems in space. 
SDI may require that researchers put 
databases with trillions of bits of infor¬ 
mation on platforms in space and pro¬ 
vide communication links between these 
orbiting computer centers and Earth. 
What is SDIO’s approach to this 
monumental undertaking? “We have 
never put a big information-processing 
system in space. We have to learn about 
putting software systems in space, main¬ 
taining it, validating it, verifying it on a 
day-to-day, moment-to-moment situa- 

The speaker said that by the early 
1990’s a research internet for SDI would 
be instituted. This internet would be to 
SDI what ARPAnet is to DARPA. It 
would not only function as a 
research network but would serve as a 
prototype of the distributed system 
proposed for the battle management 
software. 


First issue of journal 
dedicated to King-Sun Fu 

The first issue the International 
Journal of Pattern Recognition and Arti¬ 
ficial Intelligence, to be published as a 
quarterly beginning in spring 1987, will 
be dedicated to the memory of the late 
King-Sun Fu. 

A pioneering researcher in the field of 
pattern recognition and an active 
member of the Computer Society, Fu 
was the first editor-in-chief of the IEEE 
Transactions on Pattern Analysis and 
Machine Intelligence and served as the 
society’s vice president for publications 
in 1982-83. 

For additional information on the new 
quarterly, write to Journal Dept., World 
Scientific Publishing Co. Pte. Ltd., 
Farrer Rd., PO Box 128, Singapore 
9128. 


Continuing a policy initiated two 
years ago, Coopers & Lybrand has ex¬ 
amined the Computer Society’s financial 
records. The accounting firm’s report 
for the years ended December 31, 1985 
and 1984, appears below. 

Board of Governors of 
IEEE Computer Society 

We have examined the balance sheets 
of IEEE Computer Society as of 


December 31, 1985 and 1984, and the 
related statements of revenue, expenses, 
and changes in fund balance for the 
years then ended. Except as explained in 
the following paragraph, our examina¬ 
tions were made in accordance with 
generally accepted auditing standards 
and, accordingly, included such tests of 
the accounting records and such other 
auditing procedures as we considered 
necessary in the circumstances. 


IEEE Computer Society Balance Sheets 
December 31, 1985 and 1984 


Assets 

1985 

1984 

Current assets: 

Cash, including interest-bearing accounts 

$ 304,900 

$1,994,700 

Investments (Note 3) 

1,811,600 

1,123,800 

Accounts receivable, trade, less allowance of 

$81,000 in 1985 and $49,200 in 1984 

610,400 

726,200 

Receivable from Institute of Electrical and 

Electronics Engineers, Inc. (Note 8A) 

84,000 

119,200 

Conference advances, less allowance 

of $6,500 in 1984 

188,900 

204,000 

Inventory 

305,700 

196,800 

Prepaid expenses and other assets 

568,700 

442,100 

Total current assets 

3,874,200 

4,806,800 

Fixed assets, net (Note 4) 

3,497,800 

979,500 

Total assets 

$7,372,000 

$5,786,300 

Liabilities and Fund Balance 

Current liabilities: 

Accounts payable and accrued expenses 

806,500 

581,800 

Note payable 

29,900 

13,600 

Deferred income: 

Membership fees 

430,200 

416,900 

Subscriptions 

1,893,500 

1,510,200 

Conferences 

104,800 

408,700 

Advertising and other 

181,500 

74,300 

Total current liabilities 

3,446,400 

3,005,500 

Notes payable less current portion 

1,675,100 

- 

Total liabilities 

5,121,500 

3,005,500 

Commitments (Note 6) 

Fund balance 

2,250,500 

2,780,800 


Total liabilities and fund balance $7,372,000 $5,786,300 
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As discussed in Note 9 to the financial 
statements, the Society reports revenue 
and expenses on all conferences partially 
or entirely sponsored by the IEEE Com¬ 
puter Society. However, for certain con¬ 
ferences partially sponsored by the IEEE 
Computer Society, revenue and expenses 
are reported solely on the final represen¬ 
tations of the external conference 
administrators. Consequently, IEEE 
Computer Society does not maintain or 
control supporting information for all 
conference revenue and expenses. There¬ 
fore, we have not been able to examine 
sufficient documentary evidence with 
respect thereto. 


In our opinion, except for the effects 
of such adjustments, if any, as might 
have been determined to be necessary 
had we been able to examine sufficient 
documentary evidence with respect to 
conference revenue and expenses, the 
financial statements referred to above 
present fairly the financial position of 
IEEE Computer Society as of December 
31, 1985 and 1984, and the results of its 
operations and changes in fund balance 
for the years then ended in conformity 
with generally accepted accounting prin¬ 
ciples consistently applied during the 
period subsequent to the change, with 
which we concur, made as of January 1, 


1985, in the method of accounting for 
inventory as described in Note 10 to the 
financial statements. 




Baltimore, Maryland 
February 28, 1986 


Statement of Revenue, Expenses, and Changes in Fund Balance 
for the years ended December 31, 1985 and 1984 


1985 1984 


Revenue: 

Computer Society membership fees 

$ 701,400 

$ 652,500 

Periodical subscriptions and other 
publication activities 

6,946,400 

6,024,900 

Conventions, conferences and other 
technical activities 

2,739,200 

2,947,600 

National Computer Conference 
distribution (Note 8B) 

484,600 

694,300 

Allocated transfers (Note 8C) 

95,400 

528,300 

Interest income 

151,300 

175,600 

Other income 

160,100 

103,100 

Total revenue 

11,278,400 

11,126,300 

Expenses: 

Periodical and publication activities 

7,386,300 

6,148,700 

Conventions, conferences and other 
technical activities 

3,103,600 

3,032,100 

Administration 

1,176,700 

885,400 

Interest expense 

125,500 

9,400 

Other expenses 

16,600 

28,200 

Total expenses 

11,808,700 

10,103,800 

Excess (deficit) of revenue over 

expenses before cumulative 
effect of change in accounting 
principle 

(530,300) 

1,022,500 

Cumulative effect of change in 

accounting principle (Note 10) 

- 

196,800 

Excess (deficit) of revenue 

over expenses 

(530,300) 

1,219,300 

Fund balance at beginning of year 

2,780,800 

1,561,500 

Fund balance at end of year 

$ 2,250,500 

$ 2,780,800 





Notes to 

financial statements 

1. Organization and purpose: 

The IEEE Computer Society (“Society”) 
constitution states the following: “The Socie¬ 
ty shall be organized within the Institute of 
Electrical and Electronics Engineers, Inc. 
(“IEEE”) and shall be scientific, literary, and 
educational in character. The Society shall 
strive to advance the theory, practice, and 
application of computer and information pro¬ 
cessing science and technology, and shall 
maintain a high professional standing among 
its members. The Society shall promote co¬ 
operation and exchange of technical informa¬ 
tion among its members and to this end shall 
hold meetings for the presentation and discus¬ 
sion of technical papers, shall publish techni¬ 
cal journals, and shall, through its organiza¬ 
tion and other appropriate means, provide 
for the needs of its members.” 

2. Summary of significant accounting 
policies: 

A. Reporting entity: 

The accompanying financial statements 
include all Society accounts maintained at 
the Society’s offices in Washington, DC, 
and Los Alamitos, California, and certain 
accounts maintained at IEEE Head¬ 
quarters. 

Certain general, administrative and 
other expenses of IEEE Headquarters are 
not allocated to the Society. In addition, 
the books and records of the Society’s 
chapters are maintained by the respective 
chapter treasurers, and are not included in 
the accompanying financial statements. 

B. Income recognition: 

Income from annual membership fees 
and periodical subscriptions is recognized 
during the year to which it pertains. 

C. Fixed assets and depreciation: 

Fixed assets are recorded at cost when 
purchased. The Society provides for 
depreciation of fixed assets by charges to 
revenue at rates considered adequate to 
amortize the cost of such assets over their 
estimated useful lives (5 to 10 years for of¬ 
fice furniture and equipment: 35 years for 
buildings) on a straight-line basis. 
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follows: 


During 1984, the Society adjusted the estimated depreciable lives 
of certain assets to bring the Society’s accounting practices in line 
with IEEE. The effect of this change was an increase to deprecia¬ 
tion expense in 1984 of approximately $57,600. 

When fixed assets are retired or otherwise disposed of, the prop¬ 
erty and accumulated depreciation accounts are relieved of the ap¬ 
plicable amounts and any profit or loss is reflected in revenue. 

D. Inventory: 

Inventory consists of tutorial books published by the Society 
and are stated at the lower of cost or market. Cost for the Society is 
determined on an average cost basis. 

E. Reclassification of 1984financial statements: 

Certain amounts in the 1984 financial statements have been 
reclassified to conform to 1985 classification. 

3. Investments: 

Investments consist of unrestricted deposits with IEEE which bear 
interest based on United States Treasury bill rates and are carried at 
cost which approximates market. 

4, Fixed assets: 

Fixed assets as of December 31, consist of the following: 


. the minimum rental commitments under this lease are as 

1986 $72,000 

1987 6.000 

Total lease commitments $78,000 


Total rental expense for 1985 and 1984 was $71,700 and $65,000, 
respectively 

7. Pension plan: 

The Society is a member of a defined benefit pension plan spon¬ 
sored by IEEE. The plan covers substantially all of IEEE employees, 
including those of the Society. It is the policy of IEEE toTmd pension 
costs accrued. 

Information pertaining to the Society’s share of the actuarial pres¬ 
ent value of accumulated plan benefits and net assets of this plan is 
not available. 

The Society was allocated approximately $80,720 and $62,500 for 
pension expense in 1985 and 1984, based upon its respective share of 
total payroll and benefit costs. 


Land 

Building and improvements 
Warehouse equipment 
Office furniture and equipment 

Accumulated depreciation 


1985 1984 


$1,334,400 

$ 144,000 

1,795,800 

521,600 

25,100 

25,100 

938,900 

701,300 

4,094,200 

1,392,000 

(596,400) 

(412,500) 

$3,497,800 

$ 979,500 


Depreciation expense amounted to $183,900 and $192,400 in 1985 
and 1984, respectively. 


5. Notes payable: 

Notes payable as of December 31, were as follows: 


Annual 

Interest 

Rate 1985 1984 


Note payable, May 1, 1990 
Note payable, May 24, 1988 
Equipment note paid out 
as of November, 1985 

Less: Amount due within 


prime $1,235,500 $ - 

12.0% 469,500 — 

16.5% — 13,600 

1,705,000 13,600 

29,900 13,600 


$1,675,100 


$_-0- 


The note payable due May 1, 1990, is collateralized by a first lien 
on all gross revenues of the Society and a mortgage on the 
Washington, DC, property. Repayment is in graduating amounts 
through the term of the note with the balance payable on May 1, 

1990. 

The note payable due May 24, 1988, is secured by a deed of trust 
on the Los Alamitos, California, property. Repayment is in equal 
monthly payments of $5,200 with the balance payable on May 24, 
1988. 

Annual maturities of long-term debt are as follows: 1986—$29,900 
1987—$33,000 1988—$484,100 1989—$31,000 and 1990—$1,127,000. 


6. Lease commitment and rental expense: 

The Society leases certain office facilities under a noncancellable 
operating lease which expires in January 1987. At December 31, 1985, 


8. Related party transactions: 

A. Institute of Electrical and Electronics Engineers, Inc. ("IEEE ”): 
The Society is a member of the IEEE corporate entity and is 

governed by the IEEE charter and bylaws. Within those bylaws, 
delegation of the responsibility for the Society’s operations has been 
placed with the Society’s Governing Board and Executive Com¬ 
mittee. 

Certain transactions undertaken in the normal course of business 
between the Society and IEEE have been reflected in the Society’s 
financial statements. Receivables from IEEE of $84,000 at 
December 31, 1985, and $119,200 at December 31, 1984, have been 
reflected on the Society’s financial statements. 

B. National Computer Conference ("NCC”): 

The Society, in conjunction with AFIPS and three other organi¬ 
zations, sponsors the annual National Computer Conference. The 
NCC offers a broad agenda relating to many areas of the computer 
field. Any surplus generated by the NCC is allocated 50% to 
AFIPS, 15% to the Society and the remaining 35% to the other 
organizations. The Society was allocated $484,600 in 1985 and 
$694,300 in 1984 of the surplus generated by the NCC. 

C. American Federation of Information Processing Societies 
( "AFIPS”): 

The Society is one of eleven members of AFIPS and is rep¬ 
resented by three members on the AFIPS Board of Directors. Any 
Surplus which AFIPS generates (primarily from the National Com¬ 
puter Conference) is allocated to the sponsoring societies based 
upon their respective board representation. The IEEE Foundation 
was allocated $95,400 in 1985 and $528,300 in 1984 of the surplus 
generated by AFIPS. The IEEE Board of Directors authorized a 
transfer from the IEEE operating fund in the sum of $95,400 and 
$528,300 to the IEEE Computer Society in 1985 and 1984, 
respectively. 

9. Conferences sponsored by the Society: 

The Society reports its share of revenues and expenses on all confer¬ 
ences partially or entirely sponsored by the Society. Supporting 
documentation of the financial activity of those conferences entirely 
sponsored by the Society is maintained at the Society’s offices. 
However, for certain conferences partially sponsored by the Society, 
supporting documentation is maintained by the conference ad¬ 
ministrators and only a summary final report of the financial activity 
is received by the Society. 

10. Change in accounting principle—inventory: 

Effective with the year ended December 31, 1984, the Society 
changed its method of accounting for costs associated with the 
publication and printing of tutorial textbooks. These costs, which in 
prior years had been expensed in the period incurred, have been 
capitalized and recorded as inventory at December 31, 1985 and 1984. 
This change was made to achieve a better matching of costs and 
revenues. 
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NEW PRODUCTS 


Apple unveils new personal computer: the Apple IIGS 


Apple Computer, Inc., has added a 
new high-end member to its Apple II 
family of personal computers—the Ap¬ 
ple IIGS, which is designed especially for 
applications in which either advanced 
graphics or sound is important. 

In standard configuration, the Apple 
IIGS has 256K bytes of RAM, 128K 
bytes of ROM, and eight expansion 
slots. Built into the system are two serial 
ports; a jack for head-phones or external 
speaker; a joystick port; ports for analog 
red-green-blue (RGB) and composite col¬ 
or video monitors; an Apple DeskTop 
Bus port for keyboard, mouse, and other 
input devices; and a disk interface for 
both 5.25-inch and 3.5-inch disk drives. 

The new 16-bit 65C816 microprocessor 
enables the IIGS to run existing applica¬ 
tions nearly three times as fast as other 
members of the Apple II family, the 
company says. The internal memory of 
the IIGS is expandable from 256K bytes 
to 1M byte via an expansion card. Apple 
says that with the eventual development 
of additional Apple and third-party ex¬ 


pansion cards, the IIGS will ultimately 
be expandable to 8M bytes of RAM. 

Like the Macintosh, the IIGS incor¬ 
porates a communications chip that sup¬ 
ports the AppleTalk network, which 
gives the IIGS the potential to print on a 
LaserWriter printer and connect with 
other Apple computers. Also like the 
Macintosh, the Apple IIGS contains in 
ROM the “QuickDraw” graphics rou¬ 
tines that make possible pull-down 
menus, windows, and icons. 

The Apple IIGS runs approximately 
90 percent of the software and nearly all 
of the peripherals developed for earlier 
Apple II computers. 

Software packages that do not func¬ 
tion normally on the IIGS fall primarily 
into two categories: those that do not 
conform to Apple programming guide¬ 
lines and those that require the com¬ 
munications chip found on the Apple 
Super Serial Card. 

Communications software that re¬ 
quires an Apple II Super Serial Card will 
not operate normally with a modem 


IBM releases fastest, most powerful PC XT 


IBM has announced the availability of 
its Personal Computer XT Model 286, 
which, the company says, is its fastest, 
most powerful IBM Personal Computer 
XT. 

The new personal computer is com¬ 
patible with the IBM family of personal 
computers. 

Included in its standard features are an 
Intel 16/24-bit 80286 microprocessor. 

This microproces«*>r addresses up to 16M 
bytes of RAM and has a 6-MHz clock 
speed with zero wait-state for memory 
operations. 

The microprocessor operates in real 
address mode (default) and protected 
virtual mode. In real address mode, the 
80286 is 8088-compatible and therefore 
permits most software designed for other 
members of the IBM PC family to 
operate on the IBM PC XT Model 286. 

The microprocessor offers protected 
virtual mode, which provides separation 
and protection of programs and data in 
multitasking environments. In this mode, 
the 80286 can address up to 16M bytes 
of real memory and 1G byte of virtual 
memory. 

Other features of the PC XT Model 
286 include 


• 640K bytes of RAM on the planar 
board, 

• a 20M-byte fixed disk capable of 
storing the equivalent of 10,000 
pages of information, 

• fixed disk and diskette adapter sup¬ 
porting up to three internal storage 
devices, and 

• eight input/output or expansion 
slots (five 16-bit; three 8-bit, two of 
which support short cards only). 

Another feature is a 1.2M-byte, 
5!4-inch, half-high, double-sided 
diskette drive supporting diskettes that 
provide, the company says, four times 
the storage capacity of 320K-/360K-byte 
diskettes. Data stored on diskettes by 
means of this drive can be read by either 
an IBM PC AT or PC XT Model 286. 

The 1.2M-byte drive can also read 
data stored on diskettes by other 
members of the IBM PC family by 
means of a 320K-/360K-byte diskette 

The IBM PC XT Model 286 has a 
serial/parallel adapter requiring only one 
slot. A maximum of two serial/parallel 
adapters are supported. 

IBM PC-DOS users require DOS Ver¬ 
sion 3.2. IBM PC Xenix Operating 


plugged into the built-in serial port. The 
IIGS contains a different communica¬ 
tions chip (the same chip that is in the 
Macintosh) from the one found on the 
card; this chip provides AppleTalk pro¬ 
tocols, a wider selection of bits-per-sec- 
ond rates and other enhancements. 

The IIGS has two graphics modes: 

• 640 x 200 pixels, palette of 4096 
colors, and 4-to-16 colors per scan 
line; and 

• 320 x 200 pixels, palette of 4096 
colors, and 16 colors per scan line. 

It also features a 32-oscillator chip 
that can play up to 15 voices simultane¬ 
ously for synthesizing both music and 
human speech. 

The suggested retail price of the IIGS 
is $999. 

For further information, contact Ap¬ 
ple Computer, Inc., 20525 Mariani Ave., 
Cupertino, CA 95014; (408) 996-1010. 
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System users require Xenix Version 2.0. 

The single-unit price for the Personal 
Computer XT Model 286 is $3995. 

For further information, contact IBM 
Corp., Information Systems Group, 900 
King St., Rye Brook, New York 10573; 
(914) 934-4488 and Rolm, 4900 Old Iron¬ 
sides Dr., Santa Clara, CA 95054; (408) 
986-1000. 
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Compaq announces new 
member of Deskpro 286 line 

Compaq Computer Corp. has 
produced a new model of the Compaq 
Deskpro 286 personal computer. 

The Deskpro 286, Model 20 has a 
20M-byte fixed disk, 640K bytes of 
RAM, a 1.2M-byte diskette drive, and 
an 8-MHz 80286 processor. It carries a 
suggested resale price of $3999. 

Further information is obtainable by 
contacting Compaq Computer Corp., 
20555 FM149, Houston, TX 77070; (713) 
370-0670. 
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EEsof CAE program designs combline filters 


EEsof, Inc., has announced a CAE 
program created for the design of comb¬ 
line filters—Filter III: Combline Design 
(CLD). 

Intended for microwave engineers 
using IBM PC and PC-compatible com¬ 
puters, CLD is an aid in designing comb¬ 
line bandpass filters that use constant 
diameter rods to achieve exact equal- 
ripple passband response. It allows the 


user to investigate geometry/perfor¬ 
mance tradeoffs so as to meet electrical 
requirements. 

CLD designs broad bandwidth (2:1) 
filters with two to 20 resonators; the 
filters can be configured with the 
capacitive loading in either the cover or 
the resonator. CLD creates equivalent 
circuits that contain all line element im¬ 


pedances as well as resonator loading 
capacitor values. 

CLD sells for $7500; quantity dis¬ 
counts are available. 

For information, contact EEsof, Inc., 
31194 La Baya Dr., Westlake Village, 

CA 91362; (818) 991-7530. 
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End-user expert system configures multiplexer networks 


TI adds ECD System option 
to Business-Pro computers 

Texas Instruments has added an 
Enhanced Color Display (ECD) System 
option to its Business-Pro computer 
family, for whose members it can be 
used as a high-resolution, IBM PC AT- 
compatible monitor. 

The company is also adding four 
models with ECD graphics capability to 
its Pro-CAD 286 product family. 

The ECD System includes the TI 
Enhanced Video Adapter card and the 
Enhanced Color Display unit, which is 
compatible with IBM enhanced graphics 
products. The system is based on the 
IBM Enhanced Graphics Adapter 
standard, and it includes a 13-inch screen 
with 640 x 350 pixel resolution and a 
palette of 64 colors, any 16 of which can 
be displayed at one time. 

The four new Pro-CAD 286 systems 
come standard with 640K bytes of RAM, 
an 80287 numeric coprocessor (operating 
at 8 MHz), a 40M-byte Winchester disk, 
a 1.2M-byte floppy disk, and MS-DOS 
3.0. 

The new models and their suggested 
US prices are 

• Model E40 with AutoCAD software 
(Version 2.5 with Advanced Drafting 
Extensions 1, 2, and 3) and the 
Enhanced Color Display System ($9445); 

• Model E40 without AutoCAD soft¬ 
ware, but with the ECD System ($7145); 

• Model 40 with AutoCAD software, 
but without the ECD System ($8295); 
and 

• Model 40 without AutoCAD soft¬ 
ware and without the ECD System 
($5995). 

Additional options are available from 
TI to expand the Pro-CAD 286 systems. 
The ECD System can be purchased sepa¬ 
rately for $1695. 

For more information, contact Texas 
Instruments, Inc., Data Systems Group, 
PO Box 809063, H-886, Dallas, TX 
75380-9063; (800) 527-3500. 
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CASE Communications, Inc., has in¬ 
troduced the 5010ES-DCX, which it says 
is the first end-user expert system for 
configuring multiplexer networks. 

In addition to initial configuration of 
DCX networks, the 5010ES-DCX can be 
used to reconfigure DCX networks when 
equipment is added or requirements 
change. 

The system is the initial product in the 
CASE 5000ES Series of expert systems 
for data communications management. 
It is available as an integrated subsystem 
for standard CASE Communications 


Western Digital Corporation has 
unveiled end-user versions of its 
Star LAN products that run with Novell 
software and, through a NetBIOS 
emulator, IBM PC local area network 
and compatible software. 

Western Digital’s StarLAN products 
include the WD8000S, a station board; 
the WD8000SH, a station board with in¬ 
tegral mini-hub; and the WD8010, a 
stand-alone 10-port hub. 

Both station boards plug directly into 
the IBM PC, PC XT, PC XT Model 
286, and the PC AT or compatible add¬ 
on slots. 

The WD8000SH integrates full hub 
capability into the station. This mini-hub 
feature allows up to 10 stations to be at¬ 
tached in daisy chain fashion. 

Along with the hardware, Western 
Digital is offering two optional software 
operating systems, including Novell’s 
Advanced NetWare, 86 and 286, and a 
NetBIOS emulator that allows these 
products to run under IBM’s PC Local 
Area Network Program and other Net¬ 
BIOS-compatible software applications. 

Any two hubs, the WD8010 or the 
WD8000SH, can be up to 800 feet apart. 


5000 Series Network Management 
Systems. 

The 5000ES Series is based on 
OPS-83, an AI software development 
tool designed at Carnegie Mellon Univer¬ 
sity. OPS-83 is programmed in C and 
runs under Unix; it can be ported direct¬ 
ly onto CASE equipment. 

The 5010ES-DCX is priced at $15,000. 

For more information, contact CASE 
Communications, Inc., 7200 Riverwood 
Dr., Columbia, MD 21046-1199; (301) 
290-7710. 
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An entire network can communicate 
over 10 levels of hubs and span a total of 
up to 16,000 feet. Data is transferred at 
1M bit per second. 

Network fault recovery allows each 
hub to take over the network header hub 
function automatically in the event that 
the hub level above it fails. 

The WD8010 10-port hub has a sug¬ 
gested retail price of $495. The station 
boards have suggested retail prices of 
$275 with integrated mini-hub and $199 
without. 

Novell Advanced NetWare/86 applica¬ 
tions software supporting eight stations 
is priced at $895. The same package sup¬ 
porting up to 100 stations retails for 
$1595. 

The Novell Advanced NetWare/286, 
supporting up to 100 stations, retails for 
$1695. The NetBIOS emulator software 
retails for $49. 

For further information, contact 
Western Digital, 2445 McCabe Way, 
Irvine, CA 92714; (714) 863-0102. 
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StarLAN products use popular networking software 
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PC has 8.0 MHz, no wait state capability 


Sperry Corp. has introduced its 
smallest 80286-based personal com¬ 
puter—the Sperry PC/microIT, whose 
speed of 8.0 MHz and no wait states the 
company claims is 48 percent faster than 
that of similar systems. 

The PC/microIT has a footprint of 
15 X 15 inches. It incorporates an 80286 
processor with user-selectable clock 
speeds of 6.0, 7.16, or 8.0 MHz opera¬ 
tion. The 8.0-MHz speed can be con¬ 
figured with zero or one wait state. 

The single-user PC/microIT incor¬ 
porates a 16-bit open architecture, MS- 
DOS as standard, VLSI circuit tech¬ 
nology, and surface mount device 
technology. 

It can be configured as a low-end mul¬ 
tiuser system for up to five users under 
the Xenix System V Operating System. 

PC/microIT was designed to support 
8- and 16-bit feature cards. All of Sperry’s 
PC peripherals are available for it. 

The personal computer is available in 
two versions: basic and expanded. The 
basic system is sold without disk drives; 
the expanded version includes a 
20M-byte fixed disk drive as standard. 

The standard user memory of 512K 
bytes can be increased up to 1.5M bytes 
without an expansion slot or up to 3.5M 
bytes with a single card. 

Users have the option of installing a 
1.2M-byte diskette drive or a 360K-byte 
diskette drive plus a nonremovable 
20M-byte fixed disk drive. 


Other options include a 20M-byte on- 
card hard disk drive to allow a 20M-byte 
storage configuration with two diskettes. 

The half-height fixed disk occupies a 
device space plus a card slot for its con¬ 
troller, while the on-card disk requires 
only a single expansion slot. 

Both versions contain such standard 
features as configuration switches 
mounted on the front of the system 
unit, Centronics parallel interface and 
RS-232-C serial port, five full-length ex¬ 
pansion slots, MS-DOS 3.1 Operating 
System, and a G-W Basic Interpreter. 

When the expanded system is to be 
used in a low-end, multiuser environ¬ 
ment a multiterminal adapter card pro¬ 
viding four additional RS-232-C serial 
ports can be added, as can the Xenix 
Operating System, Release V. 

A basic Sperry PC/microIT is priced 
at $2345 in single-unit quantities and 
includes 512K bytes of memory, 
operating system software, and user 
documentation. 

An expanded system is priced at $3590 
in single-unit quantities and includes 
512K bytes of memory, a 20M-byte hard 
disk, operating system software, and 
user documentation. 

For further information, contact 
Sperry Corp., World Headquarters, Blue 
Bell, PA 19424-0031; (215) 542-4213. 
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WYSEpc + has twice the clock speed of IBM PC 


Color AI VAXstations offer 
choice of operating systems 

Two high-end members of the AI 
VAXstation family, the AI VAX sta- 
tion/GPX (Graphics Extension) color 
workstations, have been announced by 
Digital Equipment Corp. 

They are designed to enable users to 
develop and deliver applications combin¬ 
ing artificial intelligence and conven¬ 
tional programs. 

The workstations feature high- 
resolution 8-plane color graphics and 
VAX Lisp, and offer users a Common 
Lisp environment with either the 
Micro VMS or Ultrix-32 operating sys¬ 
tem. (The Ultrix 32 is Digital’s native 
mode Unix operating system and is com¬ 
patible with AT&T’s Unix System V 
Release 2.0.) 

Priced at $63,395, both versions con¬ 
sist of a Micro VAX II central processor 
with 16M bytes of memory, 5.25-inch 
Winchester disk, 95M-byte streaming 
tape cartridge system, Ethernet interface, 
19-inch color monitor, keyboard, 

3-button mouse, VAX Lisp, and GKS 
graphics software. Window managers 
software is also included. 

For more information, contact Digital 
Equipment Corp., Maynard, MA 
01754-2571. 
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Late Magazines? 
No Magazines? 
Membership 
Status Problems? 


Wyse Technology has announced the 
availability of its WYSEpc +, which, the 
company clain ;, has a clock speed that 
is up to two times faster than that of the 
IBM PC. 

The WYSEpc + can run at either 9.54 
MHz or switch to the standard 
4.77-MHz clock speed through a dual¬ 
mode IBM PC-compatible 8088-1 
processor. 

Standard features on the WYSEpc + 
include the dual-processing speed 
offering 9.54-MHz mode and 4.77-MHz 
mode, a built-in monochrome/color 
graphics adapter, a 256K-byte CPU 
board expandable to 640K bytes of 
RAM, two serial ports, one parallel port, 
a real-time clock with battery backup, 
and a choice of IBM PC-AT style or 
enhanced-style keyboards. 

The built-in graphics and color 
capabilities of the WYSEpc + provide 
compatibility with IBM monochrome 
and color graphics adapters, the 


Hercules monochrome graphics adapter, 
and other display adapters. 

The built-in adapter also provides 16 
different shades of gray and various pos¬ 
sible screen resolutions, including 132 
columns by 44 lines, and flicker-free 
scrolling. 

The WYSEpc + can be configured 
with a single floppy disk drive, a dual 
floppy disk drive, or a 20M-byte hard 
disk. Two slots remain free for further 
expansion after basic configuration. 

The suggested list price of the single- 
floppy model WY-1400-01 is $1265; the 
dual-floppy model is priced at $1445. 

The 20M-byte model WY-1400-20 has a 
suggested price of $1995. 

Further information can be obtained 
by contacting WYSE Technology, 3571 
N. First St., San Jose, CA 95134; (408) 
433-1000. 
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No Answers 
To Your 
Complaints? 

Let your 
Computer 
Society 
Ombudsman 
cut 

through 
the red 
tape 
for you. 

Computer Society 
Ombudsman 
IEEE Computer Society 
10662 Los Vaqueros Circle 
Los Alamitos, CA 90720 
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X-40 system reaches 3.7 MIPS, can support 64 users 


Honeywell, Inc., has introduced the 
XPS-100 Series, a family of systems 
whose hardware, designed and manu¬ 
factured by Honeywell, offers processing 
speeds as high as 3.7 MIPS and support 
for up to 64 users. 

The operating system for the three 
members of the XPS-100 Series is based 
on Unix System V, Release 2. 

The three members are the X-10, 

X-20, and X-40. Both the X-20 and X-40 
models are configured around the Mo¬ 
torola MC68020 microprocessor, while 
the entry-level X-10 model uses the 
MC68010. Multibus-1 is incorporated on 
the X-10, VMEbus on the X-20 and 
X-40. 

The XPS-100 Series also supports mul¬ 
tilevel, multivendor communications, 
including asynchronous, bisynchronous, 
and IBM SNA connections, Ethernet 
local area networks, and public data 
networks. 

Each model can be expanded. The 
X-10 can be configured with a 4K-byte 
cache, which permits a processing speed 


20-MHz 68020 VMEbus board 

Force Computers has expanded its 
zero wait state 32-bit CPU line by adding 
a 20-MHz 68020 VMEbus board at the 
high end and a 12.5 MHz 68020 engine 
at the low end. 

The company says that the CPU-21 A 
is the first VMEbus product to achieve 
20-MHz operation. A speed-matched 
68881 floating point coprocessor is in¬ 
cluded in the design. 

The CPU-21S, the 12.5-MHz 68020 
engine, also has the speed-matched 68881 
FPCP as a standard performance 
feature. 

CPU-20/21 boards incorporate 
SRAMs that are located on standard 
VMEbus companion boards and are ac¬ 
cessed via the Force Local Memory Ex¬ 


of 0.56 MIPS. The system supports up 
to 6.5M bytes of main memory, 120M 
bytes (formatted) of hard disk capacity, 
seven Multibus-1 controllers and up to 
16 workstations. 

The X-20 can be expanded with a 
16K-byte cache, which increases speed to 
2.1 MIPS. Main memory can be in¬ 
creased to 10M bytes and disk capacity 
to 435M bytes. The system will support 
up to 32 workstations, four parallel 
printers, four '/2-inch magnetic tape 
units, and up to five optional VME con¬ 
trollers. The X-20 can also be field 
upgraded to the X-40 model. 

The X-40 model comes standard with 
dual CPUs and dual 16K-byte caches, 
providing a processing speed of 3.7 
MIPS. Main memory can be increased to 
20M bytes, and disk capacity to 870M 
bytes. The system can also be expanded 
to support up to 64 workstations, eight 
parallel printers, four '/2-inch magnetic 
tape drives, and up to 11 optional VME 
controllers. 


announced 

tension (FLME) interface on a 96-pin 
DIN connector located in the center of 
each board. 

Via the FLME, banks of ultra-high¬ 
speed SRAM offer a system access time 
of 55 ns. The FLME can connect the 
CPU to a full megabyte of SRAM (two 
companion boards, each containing 64 
64K SRAMs). 

The 68020 chip remains capable of a 
full 4 G-byte address range. All CPU 
20/21 boards employ the VMX primary 
master interface as the 32-bit memory 
and I/O extension to the address space. 
All feature 512K bytes of SRAM and 
512K bytes of EPROM. 

For applications that do not involve a 
heavy schedule of mathematical pro- 


The X-10 with 0.5M bytes of memory, 
40M bytes of hard disk storage, a 
720K-byte diskette, four workstation 
ports, one printer port, the operating 
system, and Honeywell’s interface tool is 
priced at $7475. 

The X-20, including 2M bytes of 
memory, 72M bytes of hard disk storage, 
a 720K-byte diskette, eight workstation 
ports, one printer port, a streamer tape 
port, the operating system, interface 
tool, and C language is priced at 
$16,580. 

The X-40, including 4M bytes of 
memory, a 145M-byte hard disk, a 
720K-byte diskette, 16 workstation ports, 
two printer ports, a streamer tape port, 
the operating system, interface tool, and 
C language is priced at $41,630. 

More information is available by con¬ 
tacting Honeywell, Inc., at 300 Concord 
Rd„ Billerica, MA 01821; (617) 

671-2517. 

Reader Service Number 50 


cesses, the CPU-20 (16.7 MHz) and 
CPU-20A (20 Mz) leave out the 68881 
FPCP capability. 

MTOS and pSOS kernels are avail¬ 
able, as are P-DOS and UniFLEX 
operating systems. 

Prices: The CPU-21S is priced at 
$2995; the CPU-20, at $5695; the CPU- 
20A, at $6695; and the CPU-21A, at 
$6995. The CPU-21, a 16.7-MHz CPU 
board featuring 68881 FPCP, is priced at 
$5995. 

For further information, contact 
Force Computers, Inc., 727 University 
Ave., Los Gatos, CA 95030; (408) 
354-3410. 
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Datacopy creates scanners for Macintosh 


Datacopy Corp. has announced ver¬ 
sions of its JetReader page feed scanner 
and its Model 730 flatbed scanner for use 
with the Macintosh. 

Previously the scanners were available 
only for the IBM PC. 

The systems are designed to enable 
users of publishing programs to integrate 
images into their documents. Either sys¬ 
tem provides 300 dots per inch (dpi) or 
200 dpi scan resolution, and can capture 
images of line art or pictures up to 8/2 
by 11 inches. Smaller areas can be 
scanned by setting user-controlled scan 
windows. 


Once scanned, images can be for¬ 
matted for insertion into documents 
prepared on Desktop Publishing pro¬ 
grams, such as Aldus’s PageMaker, 
Manhattan Graphic’s MacPublisher, and 
Boston Software’s ReadySetGo. 

The JetReader uses a paper feed 
mechanism for moving the original 
material through the scanner. Up to 10 
pages can be stacked in the paper feeder. 

In the Model 730, which resembles a 
small copier, the original material is 
placed face down on the glass platen and 
the cover closed. During scanning the 
original material does not move. 


The JetReader system with Maclmage 
software and interface cables sells for 
$2250. 

The Model 730 system with Maclmage 
software and interface cables sells for 
$3250. Both will be available in produc¬ 
tion quantities in December. 

Further information is available by 
contacting Datacopy Corp., 1215 Terra 
Bella Ave., Mountain View, CA 94043; 
(415) 965-7900. 

Reader Service Number 52 
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NEW LITERATURE 


Review of Scientific Wordprocessors for 
the IBM PC. Results of a 10-month 
study to determine the kind of word¬ 
processing program needed in the scien¬ 
tist’s office. Fifty-page report also in¬ 
cludes vendor list, product reviews, and 
bibliography. Carl A. Hein, Dunster 
House, Apt. 7, Swanson Rd., Box- 
borough MA 01719; send SASE and $8. 

Worldwide Directory of Fiberoptic Sup¬ 
pliers. Quick reference guide organized 
into 22 product categories. Lists contact 
information and names of companies 
supplying fiberoptic products. Kessler 
Marketing Intelligence, America’s Cup 
Ave., 31 Bridge St., Newport RI 02840; 
(401) 849-6771; $30, domestic; $35, 
overseas. 

The Answer for Industrial Automation 
Networks—Promise and Practice. First 
of two reports on manufacturing auto¬ 
mation protocols, or MAP. Includes 
multiclient study, analysis of MAP con¬ 
cepts, present status and future devel¬ 
opments, and assessment of products 
and vendors. CIMdata, Inc., 120 Cedar 
St., Wellesley Hills, MA 02181; (617) 
235-4124; two reports, $9500, discounted 
with quantities. 


Practitioner's Guide to Ada. Robert H. 
Wallace’s 373-page guide for software 
engineers using Ada. Key concepts of 
and questions about the language are 
presented in tabular and graphical form. 
McGraw-Hill Book Co., 1221 Ave. of 
the Americas, New York, NY 10020; 
(212) 512-3493; $38.95. 

Computer Law Forms Handbook. 
Laurens R. Schwartz’s annual publica¬ 
tion provides forms and guidance for 
drafting computer contracts. Includes 
glossary, lists of relevant state and 
federal statutes and international laws, 
recent copyright guidelines, and anno¬ 
tated table of cases. Clark Boardman 
Co., Ltd., 435 Hudson St., New 'York, 
NY 10014; (800) 221-9428; $55. 

The Laser Guidebook. Presenting infor¬ 
mation on the functional characteristics 
of commercial lasers, Jeff Hecht also of¬ 
fers an overview of the field. Includes a 
glossary of laser-related terms and a 
tabulation of types of commercial lasers, 
organized by wavelength. McGraw-Hill 
Book Co., 1221 Ave. of the Americas, 
New York, NY 10020; (212) 512-3493; 
$49.50. 
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At United Technologies Research Center, we will offer you the op¬ 
portunity for professional recognition and significant achievement 
while handling a broad range of assignments in Software Research. 


Ada Technology 


Specific projects encompass research into portable windowing 
systems for Ada environments, specification and design of advanced 
Ada support tools and the application of formal techniques, eg., 
design annotations, to Ada software development. 

Preferred candidates will have a Master's or PhD degree in Com¬ 
puter Science with experience in Ada, software engineering and Ada 
environments, particularly support for advanced user interfaces. Re¬ 
search experience with concentration on data-base/knowledge-base 
management, formal specification, UNIX workstations and know- 
ledge-based software development techniques would be of significance 
United Technologies Research Center provides a superior com¬ 
pensation package. To learn more, please send your resume, in¬ 
cluding salary history and requirements, in confidence to: Dr. Wayne 
W. Kuhnly, MS 35, United Technologies Research Center, Silver lane. 
East Hartford, CT 06108. 
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Recent 1C Announcements 


MODEL AND R.S. 

FUNCTON COMPANY COMMENTS NO. 


AD7537, Analog Devices Dual, 12-bit monolithic DACs packaged in 24-pin DIPs (0.3 70 

AD7547 One Technology Way in.). The AD7537 has a 2-byte input structure for loading 

DACs Norwood, MA 02062-9106 from an 8-bit bus; the AD7547 has a 12-bit parallel loading 

(617) 329-4700 structure for loading from a 16-bit data bus. Cost: $14.50 for 

the JN grade (100’s). 


82510; UPI-452 Intel Lit. Dept. W-317; W-319 The 82410 asynchronous serial controller features on-chip 71 

UART; I/O processor 3065 Bowers Ave. CCR with two independent, 4-byte transmit and receive 

Santa Clara, CA 95052-8065 FIFOs. It also has two baud-rate generators and a software 

(408) 987-8080 configurable channel or modem interface. Comes in 28-pin 

DIP. Cost: $10.56 (1000’s). The UPI-452 combines a 
128-byte, two-channel, bidirectional FIFO buffer; a two- 
channel DMA processor; an 8K-byte EPROM; a 256K-byte 
RAM; and an MCS-51 microcontroller with 40 programmable 
I/O lines. Comes in EPROM, ROM, and external memory 
versions in 68-pin PGA packages. The ROM and ROM-less 
versions also come in 68-lead PLCC packages. Samples avail¬ 
able now. Cost: (1000’s) $70 for the EPROM and $30 for the 
ROM-less versions. 


SSI 441 Silicon Systems 

Data synchronizer/ 14351 Myford Rd. 

write precompensation Tustin, CA 92680 
IC (714)731-7110 


Designed for use with the uPD765A/uPD7265 family of 72 

floppy disk controller devices. Performs read data 
synchronization and write data precompensation for MFM 
encoded systems. Comes in a 28-pin PDIP or surface-mount 
PLCC. Cost: about $3 for the PDIP in OEM quantities. 


FDC9268 Standard Microsystems 

Disk controller 35 Marcus Blvd. 

Hauppauge, NY 11788 
(516)273-3100 


An integrated single/double density floppy disk controller 73 

that combines the FDC765A floppy disk controller with a hi¬ 
res digital data separator. Interfaces a processor to four 3.5, 

5.25, or 8-in. floppy disk drives. Comes in 40-pin plastic, 

Cerdip, and ceramic packages; 44-pin PLCC upcoming. Cost: 

$14.40 (plastic, 100’s). 


MK4511 

SRAM 


Thomson Components 
1310 Electronics Dr. 
Carrollton, TX 75006 
(214) 466-6000 


A 512-by-9 biport CMOS SRAM with two independent, 74 

address/data multiplexed ports. Uses two software- 
controllable interrupt output pins. Comes in a 28-pin, 600-ml 
DIP. Available in three speed versions: 120 ns (MK4511N12), 

150 ns (MK4511N15), and 200 ns (MK4511N20). Cost: $26.27 
(N12), $22.72 (N15), and $21.30 (N20). 


8021 Series White Technology 

Hybrid SRAM 4246 E. Wood St. 

Phoenix, AZ 85040 
(602) 437-1520 


Hybrid 8K-byte by 8 SRAMs for hostile environments, 75 

featuring a typical access time of 150 ns, operating current of 
5 mA, common data input and output, and a single 4.5V to 
5.5V power supply. Withstand temperatures of - 55 to +200 
degrees C. The 8021 comes with a single chip select, while the 
8021-1 has an additional chip select line. Both come in a 
28-pin DIP. Cost: $204 (100’s). 


Z85C30 Zilog 

CMOS SCC 1315 Dell Ave. 

Campbell, CA 95008 
(408) 370-8000 


The CMOS Z85C30 serial communications controller 76 

operates at 8 MHz, with 10-MHz versions available by 1987. 

The CMOS Z85C30 is pin compatible with its NMOS 
counterpart. Cost: $9.95 (10,000’s). 


86 


COMPUTER 










Recent Microsystem Announcements 


MODEL AND R.S. 

FUNCTON COMPANY COMMENTS NO. 


Series-400/20 
Ruggedized computer 

Aitech Systems 

60 Medinat Hayehudim St. 

PO Box 2088 

Herzelia B, 46120, Israel 
(052) 550024 

Based on the Motorola 68020 microprocessor and 68881 
floating-point coprocessor. Packaged in an aluminum alloy 
for hostile environments, weighing under 30 lbs. Provides an 
average of 2-3 MIPS at 16.67 MHz. Software support 
includes real-time operating systems, Unix System V, and AI 
application delivery. No price given. 

AMQ 286 

Portable computer 

AMQ Computer 

655 N. Pastoria Ave. 
Sunnyvale, CA 94086 
(408) 720-8055 

An IBM AT-compatible portable computer that includes four 
graphic modes built into the motherboard. Includes a 
40M-byte hard disk. Offers an optional multilingual feature. 
Cost: $5995. One language costs $375; each additional lan¬ 
guage costs $100. 

RS/Explore; 

RS/Discover 

Software 

BBN Software Products 

10 Fawcett St. 

Cambridge, MA 02238 
(617) 864-1780 

Based on RS/1. RS/Explore adds a statistical advisory 
component. RS/Discover adds creation and analysis of 
experiments. Both run on a range of DEC VAX machines. 
Cost: From $9000-$103,000 for RS/Explore and 
$44,000-$138,000 for RS/Discover depending on hardware 
configurations. 

Universe 32/117 
and 68/117 
Supermicrocomputers 

Charles River Data Systems 

983 Concord St. 

Framingham, MA 01701 
(617)626-1000 

VERSAbus-based 32-bit systems with seven expansion slots. 
The Universe 32/117 uses the 16.7-MHz Motorola 68020 mi¬ 
croprocessor and executes 3 MIPS. The 68/117 uses the 
12.5-MHz Motorola 68000 processor and executes 1.25 

MIPS. Cost: $34,000 for the 32/117 and $27,500 for the 
68/117. 

Mach Series 

FPA hardware 
and software 

Data Translation 

100 Locke Dr. 

Marlboro, MA 01752 
(617)481-3700 

32-bit floating-point-array processing hardware and software 
for the IBM PC, PC-XT, and PC-AT. Includes the DT71010 
FPA processor (hardware), Mach Vector Subroutine Library, 
Mach Microcode Assembler, and Mach Simulator. Cost: 

$4995 for the DT7010; $1495 for the Library; $1495 for the 
Assembler and Simulator; and $2495 for all three software 
products. 

DVME-104 

CPU 

DY-4 Systems 

888 Lady Ellen PI. 

Ottawa, Ontario, Canada 

K1Z5M1 

(613) 728-3711 

A single-board computer with a 10 or 12.5 MHz 68010 CPU 
and 1M byte of DRAM. Supports dual-ported memory, 
separate local and global VMEbus addresses and local and 
global memory access, and write protection. Cost: $2939. 

Titan 30 RLL 
Winchester drive 

LaPine Technology 

182 Topaz St. 

Milpitas, CA 95035 
(408) 262-7077 

A 30M-byte, 3.5-in. Winchester drive certified to work with 
run-length limited controllers. Features a head-lifter 
mechanism and a MTBF of 28,000 hours. Average access 
time of 65 ms. Cost: $340 (1000’s). 

PC-CICS 

CICS emulator 

Micro Focus 

2465 E. Bayshore Rd. 

Palo Alto, CA 94303 
(415) 856-4161 

Emulates CICS on the IBM PC, PC-XT, and PC-AT. A 
companion product to Micro Focus’ VS Cobol Workbench 
that permits CICS/VSAM programs to be prototyped on 

PCs. Cost: $1500. A run-time version costs $100. 

PME 68-12 

CPU 

Plessey Microsystems 

One Blue Hill Plaza 

Pearl River, NY 10965-8541 
(914) 735-4661 

A VMEbus-compatible single-board computer with up to 4M 
bytes of dual-ported DRAM, plus 16K bytes of SRAM. Also 
comes in 512K-byte and lM-byte versions. Runs at 10 MHz. 
Cost; $1850. 
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CALL FOR PAPERS 


Computer: Articles that cover the state 
'S' of the art and important new devel¬ 
opments in computer science, technology, and 
applications are sought. Submit materials to 
Bruce Shriver, IBM T.J. Watson Research 
Center, Route 134, PO Box 218 (HO-B04A), 
Yorktown Heights, NY 10598; (914) 945-1664. 
His electronic mail addresses are as follows: 
for Compmail +, b.shriver; for CSnet, 
shriver@ibm.com; and for Vnet, shriver at 
yktvmh. 

In addition, papers are sought for a special 
issue, which is scheduled for publication in 
May 1987, on interconnection networks for 
parallel and distributed processing. Submit six 
copies of papers by November 15, 1986, to 
the guest editor, Laxmi N. Bhuyan, at the 
University of Southwestern Louisiana, Center 
for Advanced Computer Studies, PO Box 
44330, Lafayette, LA 70504-4330. Bhuyan 
can also be reached at (318) 231-6284. 

Third Workshop on the Mathematical Foun¬ 
dations of Programming Semantics (ACM): 
April 8-10, 1987, New Orleans, Louisiana. 
Submit four copies of draft paper (12 pages 
maximum) by November 17, 1986, to either 
Michael Main, Computer Science Dept., CB 
430, University of Colorado, Boulder, CO 
80309 or Austin Melton, Computer Science 
Dept., Kansas State University, Manhattan, 
KS 66506. 

FTCS-17, 17th International Symposium on 
Fault-Tolerant Computing (IEEE): June 
17-19, 1987, Portland, Oregon. Submit six 
copies of paper by November 21, 1986, to 
Flaviu Cristian, IBM Research K55/801, 650 
Harry Rd., San Jose, CA 95120-6099. 


19th Annual ACM Sigact Symposium on 
Theory of Computing: May 25-27, 1987, New 
York, New York. Send 10 copies of a detailed 
abstract (2500 words maximum) by November 
21, 1986, to Alfred V. Aho, Computing 
Science Research Center, Room 2C-326, 

AT&T Bell Laboratories, Murray Hill, NJ 
07974. 


£3J, Sigplan 87, Symposium on Interpreters 
and Interpretive Techniques (ACM): 
June 24-26, 1987, St. Paul, Minnesota. Sub¬ 
mit 11 copies of an 8-to-10-page summary (in¬ 
cluding an abstract of 250 words or less) by 
November 28, 1986, to Thomas N. Turba, 
Sperry Computer Systems, PO Box 64942, St. 
Paul, MN 55164. 


14th International Symposium on Com- 
puter Architecture: June 2-5, 1987, 
Pittsburgh, Pennsylvania. Submit five copies 
of paper (20 pages maximum) by December 1, 
1986, to D. Siewiorek, Computer Science 
Dept., Carnegie Mellon University, Pitts¬ 
burgh, PA 15213. 


igii IEEE Transactions on Computers: 

Papers are sought for two special issues 
planned for 1987. The first will be devoted to 
real-time systems. Submit six copies of a 
paper by December 1, 1986, to Kang G. Shin, 
Dept, of Electrical Engineering and Computer 
Science, University of Michigan, Ann Arbor, 
MI 48109; (313) 763-0391. The second will be 
devoted to supercomputing. Submit six copies 
of a paper by February 1, 1987, to H. C. 
Torng, School of Electrical Engineering, Cor¬ 
nell University, Ithaca, NY 14853-5401; (607) 
255-5191. (Guidelines for submitting manu¬ 
scripts appear on the back cover of every 
issue of IEEE Transactions on Computers.) 

Third IEEE Conference on Artificial 

Intelligence Applications: February 
22-28, 1987, Orlando, Florida. Poster session 
papers (describing ongoing research) are 
sought. Submit four copies of a 1000-word 
abstract (including subject category) by De¬ 
cember 1, 1986, to James Miller and Elaine 
Rich, MCC, 9430 Research Blvd., Austin, TX 
78759. 


1987 ACM Sigmod Annual Conference on 
Management of Data: May 27-29, 1987, San 
Francisco, California. Send six copies of the 
complete paper by December 6, 1986, to 
Umeshwar Dayal, CCA, 4 Cambridge Center, 
Cambridge, MA 02142 (systems and algo¬ 
rithms stream) or Irv Traiger, K55-801, IBM 
Almaden Research, San Jose, CA 95120 (ar¬ 
chitecture and applications stream). 


CG International 87, Fifth International Con¬ 
ference on Computer Graphics in Japan 

(CGS): May 25-28, 1987, Karuizawa, Nagano 
Prefecture, Japan. Submit five copies of a 
paper of between 5000 and 10,000 words (in¬ 
clude title, abstract of up to 150 words, a 
maximum of 10 key words and phrases, short 
biography, photo, and commitment to present 
paper) by December 15, 1986, to Tosiyasu L. 
Kunii, c/o Dept of Information Science, 
Faculty of Science, the University of Tokyo, 
Hongo, Tokyo 113, Japan. 


ICCV-87, First International Con- 

ference on Computer Vision: June 8-11, 
1987, London, England. Send four copies of 
complete paper by December 15,1986, to 
Azriel Rosenfeld, Center for Automation 
Research, University of Maryland, College 
Park, MD 20742. 

ICDCS-7, Seventh International Con¬ 
es' ference on Distributed Computing 

Systems: September 21-25, 1987, Berlin, West 
Germany. Submit five copies of paper (20 
pages maximum) by January 1,1987, to G. 

Le Lann, INRIA, Rocquencourt, BP 105, 
78153 Le Chesnay Cedex, France; phone 
(331) 39 63 53 64 (authors in Europe or 
Africa) or K. H. Kim, Computer Engineering 
Program, Dept, of Electrical Engineering, 
Room 544B, University of California, Irvine, 
CA 92717; (714) 856-4821 (authors in the 
Americas, Asia, or Australia). Proposals for 
one-day tutorials are also sought. Submit 
them by the same date to Earl Swartzlander 
Jr., TRW Defense Systems Gr., One Space 
Park 02/2791, Redondo Beach, CA 90278 or 
L. Pouzin, CNET Centre Paris A, 38-40 Rue 
de Gen. Leclerc, 9231 Issy le Moulineaux, 
France. 


Third International Symposium on 
VLSI Technology, Systems, and Ap¬ 
plications: May 13-15, 1987, Taipei, Taiwan, 
Republic of China. Submit 30 copies of a 
300- to 600-word summary (include name, af¬ 
filiation, address, and telephone number), art¬ 
work, and a 35- to 50-word abstract by 
January 1, 1987, to Ben M. Y. Hsiao, IBM 
Corp., Dept. D18, Bldg. 707, PO Box 390, 
Poughkeepsie, NY 12602. 


£3^1 CSM-87, Conference on Software 
^ Maintenance (AWC, DPMA, NBS, 
SMA): September 21-24, 1987, Austin, Texas. 
Submit five copies of papers (1000 to 5000 
words; paper should be accompanied by a 
250-word abstract) and five copies of pro¬ 
posals for panel sessions (include a list of four 
to five potential panelists) by January 6, 1987, 
to Wilma M. Osborne, National Bureau of 
Standards, Bldg. 266, Room B266, Gaithers¬ 
burg, MD 20899; (301) 921-3545. 

Compass 87, Conference on Computer 
Assurance (IEEE): July 6-10, 1987, Washing¬ 
ton DC. Submit abstracts by January 31, 

1987. For submission information, contact 
Frank Houston, (301) 443-5020. 


Conferences that the Computer Society participates in or sponsors are indicated by the 
IEEE Computer Society logo; other conferences of interest to our readers are also included. 
For inclusion in Call for Papers or Calandar, submit information six weeks before the month 
of publication (e.g., for the February 1987 issue, send information for receipt by December 
15,1986) to COMPUTER, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720. 


ASPLOS-II, Second International Conference 
on Architectural Support of Programming 
Languages and Operating Systems: October 
5-8, 1987, Palo Alto, California. Submit five 
copies of full-length papers (approximately 
5000 words) or short papers (approximately 
1000 words) by February 1, 1987, to Randy 
H. Katz, Computer Sciences Division, UC 
Berkeley, Evans Hall, Berkeley, CA 94720. 
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CALL FOR PAPERS 


- 16th Annual Conference - 

1987 International Conference on 
Parallel Processing 

August 17-21, 1987 
The Pennsylvania State University 




Authors are invited to submit papers describing recent ad¬ 
vances on all aspects of parallel/distributed processing. 
These may include parallel/distributed logic circuits, im¬ 
pact of VLSI to parallel processor architecture; various 
concurrent-, distributed-, parallel-, pipeline-, or multiple- 
processor architectures; processor-memory interconnec¬ 
tions; computer networks; distributed data bases; reliabil¬ 
ity and fault tolerance, modeling and simulation tech¬ 
niques; performance measurements; operating systems; 
languages; or various application studies. 

INSTRUCTIONS FOR AUTHORS 

The conference will accept both regular and short papers. 

The deadline for submitting papers is January 15, 
1987. 

For regular papers, four copies each of a 100-word ab¬ 
stract and the full text are required. 

For short papers, authors should submit four copies each 
of a 100-word abstract and a summary of 1000 words. 

Please make sure that summaries are of sufficient de¬ 
tail to permit careful evaluation by referees. Appropri¬ 
ate references and figures should be included in the sum¬ 
maries. Please include office and/or home telephone 
numbers. 

The papers should be submitted before January 15,1987 
to 

Sartaj K. Sahni 
Dept, of Computer Science 
136 Lind Hall 
University of Minnesota 
Minneapolis, MN 55455 

Submitted papers will be acknowledged promptly and au¬ 
thors will be notified of acceptance by March 15, 1987. 

CONFERENCE PROCEEDINGS 

The regular papers and the summaries of the short papers 
will be published in the conference proceedings. Special 
sheets for the preparation of accepted papers for the pro¬ 
ceedings will be sent to each author. 

Call for Papers 


CONFERENCE AWARDS 

The conference will give two awards: one for Daniel L. 
Slotnick Award for Most Original Paper, the other for the 
Best Presentation. In addition, a small number of awards 
may be given for Outstanding Papers and Distinguished 
Presentations. 

CONFERENCE ENVIRONMENT 

The Conference will be held at the Pheasant Run Resort in 
St. Charles, Illinois. Pheasant Run is only 45 minutes from 
Chicago's loop and 25 miles from O'Hare International Air¬ 
port. 

The Resort is situated on 300 acres in the beautiful Fox 
River Valley town of St. Charles, Illinois. The 550 rooms are 
homey and gracious with scenic views of a small lake or a 
beautiful golf course. On a clear day the Chicago skyline is 
visible from the upper levels of its sleek 15 story Tower. 
Special entertainment is available nightly. Pheasant Run 
Theatre features sumptuous dining followed by profes¬ 
sional talent and critically acclaimed hit plays. 

Resort facilities include 18 hole championship golf course, 
three swimming pools, indoor and outdoor tennis courts, 
Midwest’s most complete Health Spa and Fitness Center, 
Volleyball, Basketball and River Boat rides on the Fox 
River just 3 miles from the Hotel. 

There is transportation available through the Hotel Trans¬ 
portation Department between Pheasant Run and O'Hare 
International Airport. 

Informal, open bar gatherings will be held nightly for the 
conference participants. 

A Conference brochure with pre-registration form and a 
technical program will be prepared and mailed in 
May/June 1987. 

TUTORIALS 

At the request of many conference attendees, pre-con¬ 
ference (on Aug. 17) and post-conference (on Aug. 21) tu¬ 
torials on parallel/distributed processing will be offered. 


Call for Papers 
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CALENDAR 


November 1986 

Fifth Annual VLSI Packaging Workshop 
(IEEE), November 17-18, Paris, France. Con¬ 
tact Karel Kurzweil, BULL-Rue Jean Jaures, 
78340 Les Clayes Sous Bois, France; phone 
(1) 34-62-70-48. 

IEEE Computer Networking Sym¬ 
posium, November 17-18, Washington 
DC. Contact Tuncay Saydam, University of 
Delaware, Dept, of Computer and Informa¬ 
tion Sciences, 103 Smith Hall, Newark, DE 
19716; (302) 451-2716. 

Fifth International Conference on 
'S' Entity-Relationship Approach (ACM, 
AFCET), November 17-19, Dijon, France. 
Contact Adarsh K. Arora, Gould Research 
Center, 40 Gould Center, Rolling Meadows, 

IL 60008; (312) 640-4712 or Stefano Spac- 
capietra, Universite de Bourgogne-IUT, BP 
510—21014 Dijon Cedex, France; phone 
80664611. 


Globecom 86, 1986 Global Telecommunica¬ 
tions Conference (IEEE), December 1-4, 

Houston, Texas. Contact Ross C. Anderson, 
Southwestern Bell, Room 706, 3100 Main St., 
Houston, TX 77002; (713) 521-8244. 

Real-Time Systems Symposium, De- 
cember 2-4, New Orleans, Louisiana. 
Contact John A. Stankovic, Dept, of Com¬ 
puter Science, Carnegie Mellon University, 
Pittsburgh, PA 15213; (412) 578-7668. 

1986 ACM Sigsmall/PC Symposium on Small 
Systems, December 3-5, San Francisco, 
California. Contact Jacob Slonim, Geac 
Computers, 350 Steelcase Rd. West, 

Markham, Ontario L3R 1B3, Canada. 

IEDM-86, 1986 International Electron 
Devices Meeting (IEEE), December 7-10, Los 

Angeles, California. Contact Melissa 
Widerkehr, Courtesy Associates, Inc., 655 
15th St., NW, Washington DC 20005; (202) 
347-5900. 


Third International Software Process 
™ Workshop (ACM), November 17-19, 
Breckenridge, Colorado. Contact Robert M. 
Balzer, Information Sciences Institute, 4676 
Admiralty Way, Suite 1001, Marina del Rey, 
CA 90292; (213) 822-1511 or Mark Dowson, 
Imperial Software Technology, 60 Albert Ct., 
Prince Consort Rd., London SW7 2BH, UK. 
Workshop limited to 30 people. 

Software Tools for AI/Expert Systems 
(ACM), November 24-25, Boston, Massachu¬ 
setts. Contact Warren Briggs, School of 
Management, Suffolk University, 8 Ashbur¬ 
ton PI., Boston, MA 02108; (617) 723-2349. 


December 1986 

1986 Electrical and Electronics Conference 
and Exposition (IEEE), December 1-3, Toron¬ 
to, Canada. Contact IEEE Canadian Region 
Office, 7061 Yonge St., Thornhill, Ontario 
L3T 2A6, Canada; phone (416) 881-1930. 

igj. Computer Elements Workshop, Decem- 
ber 1-4, Phoenix, Arizona. Contact 
William Rosenbluth, IBM Corp. 866-C2F, 
9500 Godwin Dr„ Manassas, VA 22110; (703) 
367-2408. 


WSC-86, 1986 Winter Simulation Con- 
^87 ference (ACM, IIE, NBS, SCS), De¬ 
cember 8-10, Washington DC. Contact James 
Henriksen, Wolverine Software Corp., 7630 
Little River Turnpike, Annandale, VA 22003; 
(703) 750-3910. 

Second ACM Sigsoft/Sigplan Symposium on 
Practical Software Development Environ¬ 
ments, December 9-11, Palo Alto, California. 
Contact Peter B. Henderson, Dept, of Com¬ 
puter Science, SUNY at Stony Brook, Stony 
Brook, NY 11794; (516) 246-7145, ext. 7090. 

1986 Decision and Control Conference 
(IEEE), December 10-12, Athens, Greece. 
Contact Anthony Ephremedes, Dept, of Elec¬ 
trical Engineering, 2443 Dept., University of 
Maryland, College Park, MD 20742; (301) 
454-6871. 


January 1987 


20th Hawaii International Conference 
on System Sciences, January 6-9, 
Kailua-Kona, Hawaii. Contact Ralph H. 
Sprague, University of Hawaii, College of 
Business Administration, R-303, Honolulu, 
HI 96822; (808) 948-7430. 


Conferences that the Computer Society participates in or sponsors are indicated by the 
IEEE Computer Society logo; other conferences of interest to our readers are also included. 
For inclusion in Calendar or Call for Papers, submit information six weeks before the month 
of publication (e.g., for the February 1987 issue, send information for receipt by December 
15,1986) to COMPUTER, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720. 


OFC-87, 1987 Conference on Optical Fiber 
Communication (IEEE), January 19-22, 

Reno, Nevada. Contact OSA Meetings Dept., 
1816 Jefferson PL, NW, Washington DC 
20036; (202) 223-0926. 


Annual IEEE Design Automation 
Workshop, January 21-23, Apache 
Junction, Arizona. Contact Jim Armstrong, 
Electrical Engineering Dept., Virginia Tech, 
Blacksburg, VA 24061; (703) 961-4723 or 
(703) 961-7078. 


14th ACM Sigact-Sigplan Symposium on 
Principles of Programming Languages, 
January 21-23, Munich, West Germany. Con¬ 
tact Steve Muchnick, Sun Microsystems, MS 
5-40, 2550 Garcia Ave., Mountain View, CA 
94043; (415) 960-7233 or Mark Wegman, IBM 
T. J. Watson Research Center, PO Box 218, 
Yorktown Heights, NY 10598; (914) 945-1327. 


IEEE Workshop on Instrumentation for 
Distributed Computing Systems, Janu¬ 
ary 22-23, Sanibel Island, Florida. Contact 
Andre van Tilborg, Computer Science Dept., 
Carnegie Mellon University, Pittsburgh, PA 
15213; (412)268-3801. 


1987 Annual Reliability and Maintainability 
Symposium (IEEE), January 27-29, 

Philadelphia, Pennsylvania. Contact V. R. 
Monshaw, RCA, Astro-Electronics, PO Box 
800, Mail Stop 55, Princeton, NJ 08540; (609) 
426-2182. 


February 1987 


iQji Third International Conference on Data 
Engineering, February 2-6, Los 
Angeles, California. Contact Gio Wiederhold, 
Dept, of Computer Science, Stanford Univer¬ 
sity, Stanford, CA 94305; (415) 497-0685 or 
Benjamin Wah, Coordinated Science Lab, 
University of Illinois, Urbana, IL 61801; (217) 
333-5216. 


Systems Design and Integration Conference 
(IEEE), February 10-12, San Francisco, 
California. Contact Deanna Myerson, Elec¬ 
tronic Conventions Management, 8110 Air¬ 
port Blvd., Los Angeles, CA 90045; (800) 
421-6816 (outside California), (800) 262-4208 
(in California). 


CSC-87, 1987 ACM Computer Science Con¬ 
ference, February 17-19, St. Louis, Missouri. 
Contact Arlan DeKock, University of 
Missouri-Rolla, Computer Science Dept., 
Rolla, MO 65401; (314) 341-4491. 
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CAREER OPPORTUNITIES 


RATES: $10 per line, $100 minimum charge (up to 
ten lines). Average six typeset words per line, 
nine lines per column inch. Add $8 for box num¬ 
ber. Send copy at least six weeks prior to month 
of publication to: Carole L. Porter, Classified 
Advertising, IEEE COMPUTER Magazine, 10662 
Los Vaqueros Circle, Los Alamitos, CA 90720. 


In order to conform to the Age Discrimination 
in Employment Act and to discourage age dis¬ 
crimination, IEEE COMPUTER may reject any 
advertisement containing any of these phrases 
or similar ones: "... recent college grads 
“...1-4 years maximum experience...,” 
“.. .up to 5 years experience...,” or ",. .10 
years maximum experience.” IEEE COM¬ 
PUTER reserves the right to append to any 
advertisement, without specific notice to the 
advertiser, "Experience ranges are suggested 
minimum requirements, not maximums.” IEEE 
COMPUTER assumes that, since advertisers 
have been notified of this policy in advance, 
they agree that any experience requirements, 
whether stated as ranges or otherwise, will be 
construed by the reader as minimum require¬ 
ments only. 


UNIVERSITY OF CALIFORNIA, DAVIS 
Chair, Division of Computer Science 

The College of Engineering, University of Califor¬ 
nia, Davis campus, is seeking a senior faculty 
member to lead its new Division of Computer 
Science to eminence. The Division has been 
allocated, initially, 15 full-time equivalent faculty 
positions. We are recruiting for several positions at 
all levels. At least two of the open positions can be 
filled with senior level faculty who have outstan¬ 
ding qualifications in the field of computerscience. 
Qualifications forthis position include an outstan¬ 
ding record of research in an area of computer 
science, demonstrated teaching ability, sensitivity 
to the needs of a complex University campus, and a 
potential for leading the faculty to develop ex¬ 
cellent research and instruction programs. Ap¬ 
plicants should send a resume and letter describing 
their interests to: 

Associate Dean Ray B. Krone 
College of Engineering 
University of California 
Davis, CA 95616 

The University of California is an Equal Oppor¬ 
tunity/Affirmative Action employer. The position 
is open until filled. 


DEPARTMENT LEADER 

The Department of Electrical Engineering at 
Washington University in Saint Louis is seeking 
a new Chairman to guide an expansion of about 
one-third from its present eighteen person level; 
additional positions are anticipated from retire¬ 
ment over the next decade. A major gift to under¬ 
write the opening phases of this development is 
already in hand. Persons desiring additional in¬ 
formation should write or telephone Professor 
Fred J. Rosenbaum, Department of Electrical En¬ 
gineering, Washington University, Saint Louis, 
Missouri 63130 [(314)889-6154]. Washinton Uni¬ 
versity is always interested in superior appli¬ 
cants regardless of race, creed, color, gender or 
age. 


GEORGE MASON UNIVERSITY 
Research Faculty Positions in 
Computer Science 

George Mason University, the state university in 
Northern Virginia, has made a major commit¬ 
ment to establish and maintain an outstanding 
academic and research program in information 
technology and engineering, including programs 
in the Departments of Computer Science, Elec¬ 
trical and Computer Engineering, Systems 
Engineering, and Information Systems, Opera¬ 
tions Research and Applied Statistics. 

Tenure track faculty positions are available in 
the Department of Computer Science with the 
nominal date of appointments commencing 
September 1987. Candidates for these positions 
must have an earned doctorate in a relevant field 
as well as outstanding personal and profes¬ 
sional qualifications and recognition for appoint¬ 
ment at the professor level, or the potential to 
achieve these at the assistant or associate pro¬ 
fessor level. They should be interested in 
teaching at the bachelors, masters, and doctoral 
level and in developing a strong research pro¬ 
gram in the areas of specialization. 

The Department of Computer Science has 20 
faculty members, who are actively engaged in 
research in the following areas: computer ar¬ 
chitecture, data communications and networks, 
software engineering, operating systems, deci¬ 
sion support systems, analysis of algorithms, 
and human and cognitive factors in systems 

The Department of Computer Science has placed 
particular emphasis on research efforts in parallel 
computation, software engineering and artificial 
intelligence. Laboratories are presently being 
developed for software engineering and artificial 
intelligence, and the department cooperates 
with the Software Engineering Institute at 
Carnegie-Mellon University. Research in parallel 
computation is coordinated through a Center for 
Parallel Computation, and faculty members have 
access to a connection machine and to the 
supercomputing facilities at the University of 
California at San Diego. 

There are numerous opportunities for encouraged 
industrial interaction in Northern Virginia, just 15 
miles southwest of the Nation’s Capital, in the 
heart of one of the country’s fastest growing 
high-technology areas. 

For full consideration, please send a detailed 
resume together with the names of four refer¬ 
ences, and any other desired supporting 
material, to: Dr. David C. Rine, Professor and 
Chair of Computer Science, George Mason 
University, Fairfax, VA 22030. Telephone calls to 
(703) 323-2713 will be welcomed. Applications 
and nominations are sought by March, 1987, and 
these will receive first priority. 

AA/EOE. 


UNIVERSITY OF GEORGIA 
Computer Science Department 

Applications are invited for tenure-track posi¬ 
tions at entry or advanced level. Excellence in 
research and teaching is being sought; all 
areas of specialization are of interest. Recently 
formed as a separate department, Computer 
Science is entering an exciting phase of 
development at Georgia. The University has 
made a major commitment to expanding the 
faculty and graduate programs in Computer 


Science. In addition to the normal computing 
facilities, there is an Advanced Computational 
Methods Center housing a CYBER 205 and a 
CYBER Plus which are available for research on 
vector and parallel computation. 

Appointments would normally commence in 
September, 1987, but different starting dates 
may be negotiated. An earned doctorate in Com¬ 
puter Science or a closely related discipline is re¬ 
quired for appointment. All applications received 
by December 31,1986 will receive full considera¬ 
tion. Applicants should supply the names of four 
references. Contact R. W. Robinson, Head, De¬ 
partment of Computer Science, 415 GSRC, Uni¬ 
versity of Georgia, Athens, Georgia 30602. The 
University of Georgia is an equal opportunity/af¬ 
firmative action institution. 


THE UNIVERSITY OF ALBERTA 
Department of Computing Science 

The Department of Computing Science is under¬ 
going an extensive expansion in research initia¬ 
tives. Applications are invited for two tenure- 
track positions at the Assistant/Associate Pro¬ 
fessor level. Responsibilities include research 
as well as teaching at the graduate and under¬ 
graduate levels. Candidates from all areas will be 
considered. Current hardware support includes 
an Amdahl 5870, a network of VAX 11/780’s, and 
well equipped microcomputer and workstation 
laboratories for graphics, VLSI, and Al research. 
Access to a Cyber 205 is available. Salary range 
is $31,612 to $50,630 and is commensurate with 
qualifications and experience. Send curriculum 
vitae, names of three references, and up to three 
reprints or papers. New Ph.D.’s should also in¬ 
clude a copy of their transcript. Apply to: Dr. Lee 
White, Chairman, Department of Computing Sci¬ 
ence, University of Alberta, Edmonton, Alberta, 
T6G 2H1. Applications will be accepted until 
December 31, 1986. The University of Alberta is 
an equal opportunity employer. 


UNIVERSITY OF MISSOURI-ROLLA 
Computer Science Faculty Positions 

The Computer Science Department at the 
University of Missouri-Rolla invites applications 
for tenured, tenure-track and visiting professor 
positions at all levels. Applicants for senior posi¬ 
tions should have demonstrated significant 
research and teaching abilities. Applicants for 
junior positions should have broad teaching and 
research interests within one or more of the 
following areas: Artificial Intelligence, Operating 
Systems, Programming Languages, Analysis of 
Algorithms, Computer Architecture and Com¬ 
puter Networks. A doctorate in Computer 
Science or a closely related area is required. 
The Department grants B.S., M.S. and Ph.D. 
degrees and has well-equipped departmental 
computing laboratories which complement ex¬ 
tensive university facilities for research and 
instruction. 

The University of Missouri-Rolla emphasizes 
science and engineering, has about 6000 
students, and is situated in a non-urban environ¬ 
ment in the Ozarks. Applications will be ac¬ 
cepted until the positions are filled. Please send 
a resume containing the names of references to: 
Search Committee, Computer Science Depart¬ 
ment, University of Missouri-Rolla, Rolla, 
Missouri 65401. 

UMR IS AN EQUAL OPPORTUNITY/AFFIR¬ 
MATIVE ACTION EMPLOYER 


November 1986 
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UNIVERSITY OF MARYLAND 
COLLEGE PARK, MARYLAND 
Information Systems 

The Information Systems department has a 
tenure-track position available at the Associate 
or Assistant Professor level. Applicants with an 
interest in both research and teaching are being 
sought. Attractive salaries are offered. 
Information Systems is an active, growing 
department at the University of Maryland. The 
graduate program attracts quality students for 
M.S. and Ph.D. degrees in Information Systems. 
Current research in our Database Systems 
Research Center includes topics in database 
systems optimization, database design, office 
information systems, knowledge based sys¬ 
tems, and systems analysis and design. 

For advantageous consideration, applications 
should be received by February 1, 1987. Can¬ 
didates should send complete resumes and 
names of three references to: Prof. Alan R. 
Hevner, Search Committee Chairperson, Infor¬ 
mation Systems, College of Business and 
Management, University of Maryland, College 
Park, MD 20742, (301) 454-3260. The University of 
Maryland is an Equal Opportunity, Affirmative 
Action Employer. Women and minorities are en¬ 
couraged to apply. 


TEXAS A&M UNIVERSITY 
Department Head 
Computer Science 

Texas A&M University invites applications and 
nominations for the position of Head of the 
Department of Computer Science in the College 
of Engineering. The Department of Computer 
Science conducts an educational and research 
program embracing major technical specializa¬ 
tions of the profession. The Department offers 
degrees at bachelors, masters, and doctoral 
levels and currently has approximately 1,200 
students of which 150 are graduate students. 
The candidate should hold a Ph.D. degree or 
equivalent in computer science, computer 
engineering, electrical engineering, or a related 
field and be nationally recognized in his or her 
field. The Head also holds the rank of Professor 
of Computer Science with tenure. Salary is 
negotiable with appointment to commence on or 
before September 1,1987. The closing for receipt 
of applications is December 1,1986. All applica¬ 
tions received by this time are assured con¬ 
sideration, but the search will continue until the 
position is filled. Applicants should send a vita 
and the names, addresses, and phone numbers 
of five references to Professor Walter Haisler, 
Chairman, Computer Science Head Search Com¬ 
mittee, Department of Aerospace Engineering, 
Texas A&M University, College Station, TX 
77843. Phone (409) 845-7541. 


Technische Universitat WIEN-AUSTRIA 

An der Technisch- Naturwissenschaftlichen 
Fakultat der Technischen Universitat Wien ist 
die neue Planstelle eines Ordentlichen Univer- 
sitatsprofessors fur Automatlsierungssysteme 
sofort zu besetzen. 

Der Bewerber/die Bewerberin soil die Lehre und 
Forschung auf dem Gebiete der Analyse, des 
Entwurfs und des Einsatzes von EDV-Systemen 
in der ProzeBsteuerung und ProzeBleittechnik 
vertreten. 

Bewerbungen sind bis 15. Oktober 1986 mit den 
ublichen Bewerbungsunterlagen (Lebenslauf, 
beruflicher Werdegang, Schriften-/Projekt- 
Verzeichnis, Sonderdrucke der drei wichtigsten 
Publikationen) an das Dekanat der Technisch- 
Naturwissenschaftlichen Fakultat der Tech¬ 
nischen Universitat Wien, Getreidemarkt 9 
A-1060 Wien (AUSTRIA) zu richten. 


TENURE-TRACK 
FACULTY POSITIONS 
GEORGE WASHINGTON UNIVERSITY 

The Department of Electrical Engineering and 
Computer Science invites applications for 
tenure-track faculty positions. We particularly 
seek persons active in the areas of Computer 
Science and Communications. Candidates 
should have an earned doctorate and research 
experience, with an interest in both teaching and 
research. Ability to attract research grants and 
contracts for support of faculty and student as¬ 
sistants is valued. The George Washington Uni¬ 
versity is located in the center of Washington, 
DC. This metropolitan area sustains the second 
largest concentration of research and develop¬ 
ment activity in the United States which creates 
a continuing demand for rigorously trained engi¬ 
neers as well as broad research opportunities. 
Our department is the largest department in the 
School of Engineering and Applied Science with 
33 full-time faculty, and a large graduate and 
undergraduate student body. The department 
has an annual research budget of close to $1 
million. Send Curriculum Vitae, list of publica¬ 
tions and references, to: 

Professor Roger H. Lang, Chairman 
Department of Electrical Engineering and 
Computer Science 

School of Engineering & Applied Science 
THE GEORGE WASHINGTON UNIVERSITY 
Washington, DC 20052 

The University is an affirmative action/equal op¬ 
portunity employer. 


GEORGIA INSTITUTE OF TECHNOLOGY 

The School of Information and Computer 
Science invites applications for faculty posi¬ 
tions at all levels. Applicants should have a com¬ 
mitment to teaching and should show a record of 
outstanding research accomplishments or ex¬ 
pect to receive a Ph.D. degree by Fall 1987 and 
show high potential for research. The School 
seeks applicants to strengthen its capabilities in 
all areas of current research activity, especially 
artificial intelligence, software engineering, dis¬ 
tributed computer systems, and also in com¬ 
puter graphics, programming languages, theo¬ 
retical computer science, human factors, VLSI 
systems, data communications and computer 
networks, database systems, and computer 
architecture. Very competitive salaries are 

The School is well supported by the Institute. It 
has 24 faculty members and is currently experi¬ 
encing substantial faculty growth. Its education¬ 
al activities include an undergraduate program 
accredited by the Computing Sciences Accred¬ 
itation Board, Inc., a Masters program with 150 
students and a Ph.D. program with over 70 
students. Well equipped separate laboratories 
support research and education. High-speed 
local area networks interconnect all major cam¬ 
pus laboratories and provide access to CSNet 
and other national networks. 

Georgia Tech is located in Atlanta, which ex¬ 
periences a mild sunbelt climate. It is the center 
of commerce In the Southeast, offering a diverse 
economy and good employment opportunities in 
all professional areas. Atlanta offers good 
cultural and recreational opportunities, extreme¬ 
ly attractive residential neighborhoods, and af¬ 
fordable housing. 

Candidates should send complete resumes and 
names of at least three references to: Professor 
Nancy D. Griffeth, Chairman, Faculty Search 
Committee; School of Information and Com¬ 
puter Science; Georgia Institute of Technology; 
Atlanta, Georgia 30332. 

Georgia Tech is an equal opportunity employer. 


LATROBE UNIVERSITY 
MELBOURNE, AUSTRALIA 
SCHOOL OF MATHEMATICAL AND 
INFORMATION SCIENCES 
Lecturer in Computer Science (tenurable) 

The appointment will commence as early as 
possible from the beginning of 1987. Applicants 
should have a PhD in Computer Science or 
related discipline and demonstrated research 
ability. Duties will include both undergraduate 
and graduate teaching and supervision of post¬ 
graduate students. 

Perference may be given to applicants with 
special interest in Software Engineering, Ad¬ 
vanced Data Structures, Distributed Computing 
and Data Communications, but applications will 
be considered from suitably qualified persons 
with a background in any area of computer 
science. The department is developing centers 
of excellence in Real Time and Co-operating 
Computer Systems and Artificial Intelligence 
(especially IKBS and Computer Vision) within a 
lively research environment. 

Further information may be obtained from Pro¬ 
fessor T. Dillon, Chairperson, Department of 
Computer Science, La Trobe University, Bun- 
doora, Victoria, 3083, Australia. 

CLOSING DATE: 19 December 1986 
Ref. No. A0/032/016 
SALARY: A$27,859-A$36,600 
Applications (marked confidential) including 
reference number, names of three referees and 
Curriculum Vitae should be forwarded to the 
Staff Officer, La Trobe University, Bundoora, Vic¬ 
toria, 3083, Australia. 


UNIVERSITY OF VICTORIA 
Faculty Positions 

Applications are invited for two tenure-track 
positions in the Department of Electrical Engi¬ 
neering at the University of Victoria. Each posi¬ 
tion will involve undergraduate and graduate 
teaching, graduate supervision at the master’s 
and doctoral levels, and research in one or more 
of the following areas: digital electronic circuits 
and hardware, VLSI design, microprocessor ap¬ 
plications, computer architectures and net¬ 
works, real-time computer systems, multipro¬ 
cessing, and artificial intelligence. 

Applicants should hold a doctorate and be famil¬ 
iar with modern trends in their area of interest, 
industrial experience will be considered an 

The Department of Electrical Engineering at the 
University of Victoria was established on July 1, 
1983 and is now housed in a new building. The 
Department offers undergraduate programs 
leading to the B.Eng. degrees in electrical and 
computer engineering, and graduate programs 
leading to the M.Eng., M.A.Sc. and Ph D. de¬ 
grees. The departmental facilities include Data 
General computers MV4000 and MV10000, many 
Sun workstations, and modern VLSI design and 
testing equipment. The departmental faculty 
strength has recently increased to 14 members. 
Victoria is situated at the southeastern tip of 
Vancouver Island and is well known for its 
flowers, superb climate, and mild winters. 

In accordance with Canadian immigration regu¬ 
lations, this advertisement is directed to Cana¬ 
dian citizens and permanent residents of 
Canada. If no suitable candidates are found, the 
search may be extended to other candidates. 
Applications, which should include curriculum 
vitae and the names of at least four referees, 
should be addressed to: 

Dr. A. Antoniou, Chairman 
Dept, of Electrical Engineering 
University of Victoria 
P.O. Box 1700, Victoria, B.C. 

CANADA V8W 2Y2 
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TEXAS A&M UNIVERSITY 
Department of Computer Science 

Applications are invited for faculty positions at 
the Assistant, Associate or Full Professor level. 
Candidates from all areas of computer science 
will be considered. Of particular interest are 
areas central to the design of fifth generation 
computer systems. In addition to regular faculty 
positions, an endowed chair in computer ar¬ 
chitecture is to be filled. 

The Department of Computer Science has 20 
full-time equivalent senior faculty members and 
additional teaching staff. There is a tradition of 
quality instruction at the B.S., M.S. and Ph.D. 
levels. The university has initiated a major com¬ 
mitment to develop excellence in Intelligent 
Systems, Artificial Intelligence, Software 
Technology, Simulation and other areas of Com¬ 
puter Science. This commitment is in support of 
the rapid build up of microelectronics and com¬ 
puter technology in Texas, and in particular the 
decision of the Microelectronics and Computer 
Technology Corporation (MCC), the industry¬ 
wide consortium of computer manufacturers in¬ 
terested in fifth generation computer systems, 
to locate nearby. 

Computer Science at Texas A&M University is 
located in the College of Engineering. With near¬ 
ly 10,000 students, the College of Engineering is 
the nation's largest. Computer Science is expand¬ 
ing to become one of the largest and more com¬ 
prehensive departments in the country. 

We seek excellence in research. Texas A&M will 
provide superior instructional and research 
facilities for its Computer Science faculty. The 
University has the internal resources to achieve 
this goal. Applicants at the assistant professor 
level should show substantial promise for 
research and teaching. Applicants at the higher 
level should show a strong record of research 
achievement. Ability in teaching graduates and 
undergraduates is also essential. All appoint¬ 
ments are made on a 12 month basis and 
academic salaries are highly competitive. 
Applicants should submit a resume and three 
references to: Glen N. Williams, Head, Computer 
Science Department, Texas A&M University, Col¬ 
lege Station, TX 77843. 

Texas A&M University is an equal opportunity/af¬ 
firmative action employer. 


OAK RIDGE NATIONAL LABORATORY 
Postdoctoral Research Opportunities 

The Machine Intelligence & Advanced Computer 
Systems Group of the Engineering Physics and 
Mathematics Division at ORNL invites applica¬ 
tions from qualified personnel with doctoral 
degrees in the disciplines of Applied Mathe¬ 
matics (nonlinear dynamical systems), Com¬ 
puter Science (real-time operating systems), 
Physics (statistical mechanics, nonlinear 
optics), Electrical Engineering (control), 
Chemistry, and Biology (computational neuro¬ 
sciences). Appointees will be involved in 
research and development activities related to 
Advanced ElectroOptic Neurocomputers, Com¬ 
binatorial Optimization, Virtual Time Operating 
Systems for Hypercube Supercomputers. The 
application of this work will focus on the Strate¬ 
gic Defense Initiative, Battle Management/C 3 -I 
program and the Department of Energy In¬ 
telligent Autonomous Systems Program. 

For information on the research program contact 
Dr. Jacob Barhen of ORNL at (615) 574-6162; for 
other information and applications contact 
Postgraduate Research Program, University Pro¬ 
grams Division, Oak Ridge Associated Univer¬ 
sities, P.O. Box 117, Oak Ridge, TN 37831, (615) 
576-3190. Only U.S. citizens and permanent resi¬ 
dents eligible. 


WORCESTER POLYTECHNIC INSTITUTE 

The Computer Science Department invites ap¬ 
plications for tenure track faculty positions at all 
levels from candidates in all areas of specializa¬ 
tion. Candidates should have a Ph.D. in Com¬ 
puter Science and a strong interest in both 
research and teaching. 

Worcester Polytechnic Institute emphasizes 
quality in the undergraduate learning experience 
and is committed to an innovative project- 
oriented teaching environment. The quality of 
the undergraduate computer science degree has 
been recognized by the recent granting of ac¬ 
creditation by the Computing Sciences Ac¬ 
creditation Board. 

The current goal of the Institute is to enhance 
our graduate program and improve research ac¬ 
tivities. The department seeks qualified can¬ 
didates who will help us achieve these objec¬ 
tives. WPI is located close to the center of 
Massachusetts’ minicomputer industry, and ex¬ 
cellent opportunities exist for cooperative 
research and consulting. 

The Department has 12 full-time faculty with 200 
undergraduates and 35 graduate students in our 
M.S. and Ph.D. programs. Department equip¬ 
ment includes three VAX 750’s, an MV8000, 
twenty PDP-11’s, and 40 PC’s. Much of this 
equipment is networked via two ethernet cables 
and is also connected to other campus facilities 
which include a DEC 2060 and numerous VAX's. 
The Institute is committed to a new Information 
Science building and full campus networking 
facilities in the near future. 

Located only 45 miles from Boston, Worcester is 
a small city of 180,000 which has recently 
undergone a renaissance. It has eight colleges 
and universities and a rich variety of cultural 
activities. 

Please send a resume to Prof. R.E. Kinicki, Head, 
Department of Computer Science, WPI, 
Worcester, MA 01609. 

WPI is an Equal Opportunity/Affirmative Action 
Employer. 


UNIVERSITY OF CALIFORNIA, RIVERSIDE 

Applications are invited for a tenure-track or 
tenure position in Computer Science beginning 
Fall 1987. Candidates must have demonstrated 
excellence in research and teaching. Research 
specialties in all areas of Computer Science will 
be considered but we are particularly interested 
in research areas in Computer Systems or Com¬ 
puter Methodology and Applications. The posi¬ 
tion is open as to the level of appointment. 
Applicants should send a curriculum vitae and 
see that at least three letters of recommendation 
are sent to: 

Professor Theodore J. Barth, Chair 
Computer Science Search Committee 
Department of Mathematics and Computer 

University of California 
Riverside, CA 92521 

University of California, Riverside, is an Affir¬ 
mative Action/Equal Opportunity Employer. 


SOFTWARE ENGINEER 

Design and develop turn-key computer systems 
for securities broker-dealers, using DEC PDP-11 
with RT-11 and TSX + in DIBOL, able to control 
25 work stations for business automation. Install 
systems and instruct clients in use. Salary: 
$2288 per mo. Must have B.S. with one year ex¬ 
perience or M.S.; degree may be in Math with 
strong Computer Science background or in 
Computer Science with strong math back¬ 
ground. Must know DEC PDP-11, RT-11 and 
TSX +, and DIBOL. Job and interview in Costa 
Mesa, CA. Send this ad and resume to: Job# 
FC6674, P.O. Box 9560, Sacramento, CA 
95823-0560, no later than December 1, 1986. 


UNIVERSITY OF MINNESOTA 

University of Minnesota Department of Elec¬ 
trical Engineering has several tenure track or 
tenured faculty positions in Electrical Engineer¬ 
ing available at all levels. The duties will include 
research and teaching in one or more of the 
following areas: microelectronics, integrated cir¬ 
cuit design, integrated optics, device physics, 
research and applications of large scale com¬ 
puting, computer systems, digital signal pro¬ 
cessing and communications, computer-aided 
design and design automation, robotics and 
electric energy systems. 

The Electrical Engineering Department has 42 
faculty members providing undergraduate and 
graduate education and pursuing research in all 
areas of electrical engineering. The State-funded 
Microelectronics and Information Sciences Cen¬ 
ter and Supercomputer Institute at the University 
of Minnesota will provide opportunities for inter¬ 
disciplinary research in cooperation with indus¬ 
try. The Department has a complete integrated 
circuit fabrication and design lab, access to Cray 
supercomputers, and other facilities. 

A successful candidate is expected to establish 
a sponsored research program. The require¬ 
ments include an earned Doctorate. Rank and 
salary will be commensurate with qualifications 
and experience. Temporary and visiting posi¬ 
tions are also available. Send applications and 
resumes to: 

Professor Michael Shur, Chairman of the 
Faculty Recruiting Committee, Department of 
Electrical Engineering, University of Min¬ 
nesota, 123 Church Street Southeast, Min¬ 
neapolis, MN 55455 

Last date for receiving applications: August 30, 
1987, for positions available September 16,1987. 
Review and interviews may begin as early as 
November 15, 1986 and early decisions may be 
made on some positions. 

The University of Minnesota is an equal oppor¬ 
tunity educator and employer and specifically in¬ 
vites and encourages applications from women 
and minorities. 

TULANE 

The Department of Computer Science invites ap¬ 
plications for faculty positions beginning in 
January/August, 1987. 

Tulane is a major private university, selective in 
enrollment and comprehensive in scope, with 
about 10,000 undergraduate and graduate 
students. The campus is located in a residential 
area of uptown New Orleans, one of America's 
most distinctive cities. Benefits include depen¬ 
dent tuition, mortgage assistance, relocation ex¬ 
penses, 12% TIAA and typical insurance 
benefits. The Department of Computer Science, 
which offers degrees at all levels through the 
Ph.D., has been specially targeted within the 
University for growth and support. 

Departmental computer systems include a VAX 
11/780 with 8 MB main memory running under 
VMS, a Pyramid 90x with 4 MB high speed main 
memory running under Unix, a Sun network, 
numerous LSI-11’s, and several microcomputer 
clusters. The Pyramid is dedicated to depart¬ 
mental research; other systems are divided be¬ 
tween research and teaching. In addition to 
departmental resources, the University main¬ 
tains an IBM 3081. 

Candidates should have a PhD in Computer 
Science or a related area. Research excellence 
or demonstrated research potential and a com¬ 
mitment to quality teaching are required. 
Applications should be directed to Dr. Johnette 
Hassell, Head, Department of Computer 
Science, School of Engineering, Tulane Universi¬ 
ty, New Orleans, LA 70118. Applications must be 
received by December xx, 1986 for January ap¬ 
pointment or March 15,1987 for August appoint¬ 
ment. Tulane University is an Affirmative Action 
Equal Opportunity Employer. 
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COMPUTER ENGINEERING 
COMPUTER AND INFORMATION SCIENCES 

Information Sciences at the University of Califor¬ 
nia, Santa Cruz, invite applications for positions 
as Assistant, Associate or Full Professor, as ap¬ 
propriate, effective July 1,1987. The Division of 
Natural Sciences at UCSC is expanding its pro¬ 
gram in Computer and Information Sciences and 
its new program in Computer Engineering. 
UCSC currently offers the B.A., M.S., and Ph.D. in 
Computer and Information Sciences, the B.A. in 
Computer Engineering, and is developing a 
graduate program in Computer Engineering. 
UCSC is the University of California campus 
nearest to “Silicon Valley” and is developing 
close ties with local industry in the computer 
field. Faculty salaries are competitive, and op¬ 
portunities for consulting are extensive. UCSC 
has several outstanding science departments, 
which have significant interests in scientific 
computing, including physics and astrophysics, 
data acquisition and reduction in astronomy 
(with the Lick Observatory and the Keck ten- 
meter telescope) and seismic data processing 
with the UCSC Richter Seismology Laboratory. 
AREAS OF INTEREST: Outstanding candidates 
from any specialty within computer engineering 
or computer science are encouraged to apply for 
these positions. Of particular interest are can¬ 
didates in computer science with strengths in 
(one or more of) the following areas: artificial in¬ 
telligence; database and expert systems; theory 
and analysis of algorithms (especially algo¬ 
rithms for language processing, scheduling, 
graphics and image processing, and parallel 
computation); and in programming languages 
and compiler construction. In computer engi¬ 
neering, candidates in areas such as software 
engineering; computer and system architecture; 
workstations, servers and networks; special pur¬ 
pose architectures (as in signal and image pro¬ 
cessing); computers as components in larger 
systems; and in computer-aided design; circuit 
and system modeling, testing, and performance 
evaluation, are of particular interest. 

RANK: Associate or Full Professor (Please refer 
to #63-867 in your reply.) 

MINIMUM QUALIFICATIONS: Ph.D. in Electrical 
Engineering, Computer Engineering, Computer 
Science, or equivalent, and a solid research 
record as evidenced by publications in technical 
journals. Applicants will be evaluated on their 
research record, teaching, professional ac¬ 
tivities and demonstrated leadership in their 
field. Industrial experience will be favorably con¬ 
sidered. 


SALARY: Commensurate with qualifications and 
experience. 

EFFECTIVE: July 1, 1987 
TO APPLY: Send applications, including cur¬ 
riculum vitae with cover letter, teaching evalua¬ 
tions, copies of any recent publications, and at 
least five letters of recommendation evaluating 
your scholarly contributions, teaching, and other 
professional accomplishments to the address 


CLOSING DATE: January 15,1987. 

RANK: Assistant Professor (Please refer to 
#64-867 in your reply.) 

MINIMUM QUALIFICATIONS: Ph.D. in Computer 
Engineering, Computer Science, or equivalent 
and demonstrated potential for research and 
teaching. 


SALARY: Commensurate with qualifications and 
experience. 

EFFECTIVE: July 1,1987 
TO APPLY: Send applications, including cur¬ 
riculum vitae with cover letter, and at least three 
letters of recommendation evaluating your 


scholarly contributions, teaching, and other pro¬ 
fessional accomplishments to the address 
below. 

CLOSING DATE: February 27, 1987 
SEND APPLICATIONS TO: 

Chair, Computer Faculty Search Committee 
Applied Sciences Building 
University of California 
Santa Cruz, California; 95064 
UCSC IS AN EEO/AA EMPLOYER 


OHIO STATE UNIVERSITY 
Department of Computer and 

Information Science 

Applications are invited for faculty positions at 
all levels. A Ph.D. in computer science or a close¬ 
ly related field is required. Of special interest are 
candidates in the areas of artificial intelligence, 
computer graphics, data bases, parallel and dis¬ 
tributed computing, software engineering, and 
VLSI design. Special research support packages 
are negotiable for highly qualified candidates. 
Research computing facilities within the Depart¬ 
ment include DEC 20/60, VAX 11/780, IBM 4341, 
AT&T 3B2, Xerox Lisp and XDE machines, Sun 
and HP workstations, and several experimental 
multi-computers (Intel Hypercube, BBN Butter¬ 
fly, etc.). In addition to the University's com¬ 
puting facilities (IBM 3081-D, etc.) the De¬ 
partment also has access to national networks 
including ARPANET and CSNET. 

To apply, please send application and resume, 
including a statement of research and teaching 
interests and the names and addresses of at 
least three references, to Prof. Ming T. (Mike) Liu, 
Chairman of Faculty Search Committee, Depart¬ 
ment of Computer and Information Science, The 
Ohio State University, 2036 Neil Avenue, Colum¬ 
bus, Ohio 43210-1277 (CSNET/ARPANET:LIU @ 
Ohio-State.) The Ohio State University is an 
equal opporunity/affirmative action employer. 

AUSTIN COLLEGE 

Tenure-track position in computer science; 
salary and rank dependent on qualifications. 
Ph.D. in computer science or closely related 
field preferred; a master’s degree or equivalent 
required. Applicants should have broad interests 
in various areas of computer science, and com¬ 
petencies in artificial intelligence and/or 
systems analysis are especially sought. In keep¬ 
ing with college’s liberal arts philosophy, can¬ 
didates should be willing to participate in 
college-wide interdisciplinary courses. Submit 
application by January 15, 1987 to: Dean David 
Jordan, Austin College, Sherman, Texas 75090. 
EOE 

FACULTY POSITIONS 

The Department of Electrical Engineering and 
Computer Science invites applications for the 
position of Assistant/Associate Professor in 
Computer Science. There are openings for two 
tenure-track positions. An applicant should have 
a doctorate with major emphasis in C.S. Good 
teaching is expected and supported. The Col¬ 
lege maintains regular budgets for faculty 
research and travel. 

Areas of interest include, but are not limited to, 
artificial intelligence, data base systems, 
algorithm design, and software engineering. 
Union College academic computing resources 
include a VAX cluster (with three 785’s, a 780, 
and a 750) running VMS 4.4 and EUNICE, as well 
as the department’s computer science lab with a 
VAX-11/750, ten DEC Pro350’s, and two AT&T 
3B2 machines all running the UNIX operating 
system. 

Applicants should write: Dr. David G. Hannay, 
Co-chairman, EE/CS Department, Steinmetz Hall 
210, Union College, Schenectady, NY 12308. 

An Equal Opportunity/Affirmative Action 
Employer. 


MASSACHUSETTS INSTITUTE 
OF TECHNOLOGY 
Faculty and Research Staff Positions 

The Department of Electrical Engineering and 
Computer Science seeks candidates for faculty 
and research staff positions starting in Sep¬ 
tember 1987. We anticipate openings for several 
junior faculty appointments for individuals who 
are completing, or who have recently completed, 
a doctorate. Faculty duties include teaching at 
both the graduate and undergraduate levels, re¬ 
search, and supervision of theses. 

We are interested in candidates in most areas of 
electrical engineering, but with special em¬ 
phasis in two areas: Compound-semiconductor 
devices, especially those involving molecular- 
beam epitaxy technology; and Control, including 
control of multivariable systems, nonlinear con¬ 
trol, and adaptive control. In computer science, 
we are interested in candidates in the following 
two areas: Computer Systems, including oper¬ 
ating systems, programming languages, com¬ 
puter architecture, databases, and graphics; and 
Al research in reasoning, including common 
sense and qualitative physical reasoning, and 
reasoning using massively parallel machines. 
Some Research Associate positions may also be 
available in the above areas. Research staff 
devote their time principally to research, with op¬ 
portunities for teaching or thesis supervision 
when appropriate. A doctorate or equivalent ex¬ 
perience is required. 

All candidates should write to the address 
below, describing their professional interests 
and goals. Applications should include a cur¬ 
riculum vitae and the names and addresses of 
three or more references. Additional material 
describing the applicant’s work, such as papers 
or technical reports, would also be helpful. All 
candidates should indicate citizenship and, in 
the case of non-US citizens, describe their visa 
status. 

Send all applications to: 

Prof. F. C. Hennie 

Room 38-435 

Massachusetts Institute of Technology 

Cambridge, MA 02139 

M.l.T. is an equal opportunity/affirmative action 
employer. 


UNIVERSITY OF WASHINGTON 

The University of Washington expects openings 
for junior and/or senior tenure-track faculty ap¬ 
pointments in Computer Science starting in the 
1987-88 academic year. A moderate teaching 
load allows time for both quality research and 
close involvement with students. As a conse¬ 
quence, we expect applicants to have a strong 
commitment to both research and teaching and 
an outstanding record of research for their level. 
A senior level applicant should have a record that 
would provide significant new research strength 
for our department. We invite applicants from all 
areas of Computer Science, quality being our 
most important selection criterion. We would 
particularly welcome applicants with research 
strength in artificial intelligence, programming 
languages and compilers, computer systems, 
and databases. In addition to the above tenure- 
track positions the department may have a 
number of visiting positions; these would re¬ 
quire both teaching and research, and could be 
for any portion of the 1987-88 academic year. 
Interested applicants should send a letter of ap¬ 
plication, a resume, and the names of four 
references to Paul Young, Chairman, Depart¬ 
ment of Computer Science FR-35, University of 
Washington, Seattle, Washington 98195. 

The University of Washington is an Affirmative 
Action/Equal Opportunity Employer. The Ph.D. is 
required for these positions. 
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OBERLIN COLLEGE 
Computer Science Faculty Position 

The Computer Science Program at Oberlin Col¬ 
lege invites applications for a full-time continu¬ 
ing faculty position in the College of Arts and 
Sciences. The position, which has been autho¬ 
rized for an initial term of 4 years beginning July 
1, 1987, will carry a rank and salary commen¬ 
surate with experience and qualification. 

The incumbent will teach courses in the general 
area of Computer Science, including at least one 
course in the appointee's area of specialization. 
In addition, he or she will have the opportunity to 
work with students in the Honors Program in 
Computer Science and will be expected to main¬ 
tain a scholarly research program. 

Among the qualifications required for appoint¬ 
ment is the Ph.D. degree in hand or expected by 
September, 1987. Candidates must demonstrate 
interest and potential excellence in under¬ 
graduate teaching. Previous experience as a 
teacher is desirable. 

The appointee will participate fully in the newly 
established majorprogram in Computer Science 
which currently has an authorized staff size of 
four faculty positions. Oberlin offers an in¬ 
novative Computer Science Major rooted in the 
liberal arts model curriculum, with some em¬ 
phasis towards symbolic programming and ar¬ 
tificial intelligence. A VAX 11/750 running UNIX 
with a full 8 megabytes of main memory and 431 
megabytes of disk storage is dedicated to the 
computer science program. Additional software 
available on this system include two Scheme 
systems, Prolog, Concurrent Euclid and Maple. 
Other computer facilities at Oberlin include two 
VAX 11/780’s for general academic computing 
and a VAX 8600 for administrative work. Access 
to CSNet and Bitnet is anticipated to begin dur¬ 
ing the current academic year. 

Oberlin is a highly selective coeducational col¬ 
lege of arts and sciences. In comparison with 
other primarily undergraduate colleges, Oberlin 
has an extraordinarily strong record in producing 
students who have gone on to earn Ph.D. 
degrees in science and mathematics. As the 
world’s first institution of higher education 
regularly to offer degrees to women and black 
students, Oberlin, in filling faculty positions, par¬ 
ticularly welcomes applications from female and 
minority candidates. 

To be assured of consideration, letters of ap¬ 
plication, including a curriculum vitae, academic 
transcripts, and at least three letters of 
reference, should be sent to George Andrews, 
Director, Computer Science Program, Oberlin 
College, Oberlin, Ohio 44074 by February 23, 
1987. Application materials received after that 
date may be considered until the position is 
filled. 


UNIVERSITY OF CALIFORNIA 
SANTA BARBARA 

The UNIVERSITY OF CALIFORNIA AT SANTA 
BARBARA invites applications for four tenure 
track positions at senior professorial levels in 
the Department of Computer Science, and for 
three additional positions in closely related 
areas, including computer engineering. The 
Department of Computer Science is in a rapidly 
expanding College of Engineering that has 
achieved national prominence in many areas of 
research. UCSB and the College of Engineering 
are highly committed to augmenting its Com¬ 
puter Science Department into a department 
that has both excellence and national visibility. 
The senior positions in Computer Science cur¬ 
rently available are in three major areas of 
research in which the Department of Computer 
Science intends to achieve its greatest strength. 
These areas are: machine vision and motion 


planning: parallel computing; and software 
engineering. These positions will provide oppor¬ 
tunities for successful candidates to guide the 
growth and development of the Department in 
these areas. Strong material support will be 
given to such positions. “State of the Art" 
laboratories are currently being planned for in¬ 
structional purposes in these areas. Research 
facilities in these areas will be made available 
and tailored to the needs of successful ap¬ 
plicants. Graduate student support will be given 
high priority. 

Interactions with various research groups on 
campus (Center for Robotic Systems, Cognitive 
Science Program, Center for Scientific Com¬ 
puting, Institute for Theoretical Physics, etc.) 
will be strongly encouraged and supported. 
Applicants must possess a doctoral degree and 
an extremely strong record of research ac¬ 
complishments. Teaching experience is desir¬ 
able. Outstanding younger candidates are also 
encouraged to apply. Deadline for receipt of ap¬ 
plications is January 15,1987. Send resume and 
names of at least eight references to: 

Chairman 

Computer Science Faculty Search 
Committee 

Department of Computer Science 

University of California 

Santa Barbara, CA 93106 
The University of California is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


CALIFORNIA STATE UNIVERSITY, 

LOS ANGELES 
Department of Electrical and 
Computer Engineering 

Faculty openings for full-time and part-time, 
tenure track (Assistant and Associate Professor) 
and temporary. Tenure track openings exist in 
Computer Software and Hardware and Systems 
and Circuits. Requirements for award of tenure 
include an earned PhD. This major urban univer¬ 
sity currently has over 1400 Electrical Engineer¬ 
ing majors at the BS and MS levels. Extensive op¬ 
portunities exist for consulting in the greater Los 
Angeles area. The department has curricular 
strength in the areas of Communications, Com¬ 
puters and Digital Systems, Control Systems, 
Power Systems, Solid State Electronics and 
Systems. Modern laboratories support the cur¬ 
ricular offerings. Industrial and/or teaching ex¬ 
perience are highly desirable. Although research 
is strongly encouraged (professional develop¬ 
ment of a continuing nature is required), we are 
primarily a teaching institution, and the desire 
and ability to communicate is of paramount im¬ 
portance. Ability to work with students on proj¬ 
ects and in advising is a consideration both for 
full-time and part-time applicants. The University 
operates year round on the quarter system, and 
full-time faculty teach three out of the four 
quarters. Classes are offered between 8 A.M. and 
10 P.M. yielding maximum scheduling flexibility 
for both students and faculty. Cal State L.A. is 
noted for its ethnic diversity. We have an active 
Minority Engineering Program with almost 200 
student participants. We also have an active 
chapter of the Society of Women Engineers. 
Minorities and women are particularly encour¬ 
aged to consider joining this dynamic institu¬ 
tion. Applications will be accepted until posi¬ 
tions are filled, but consideration during the 
major recruiting cycle requires that we receive 
your application by December 5,1986. Finalists 
will be notified by January 5, 1987, and will be 
asked to provide 3 letters of reference. California 
State University, LA, does not discriminate on 
the basis of race, color, religion, sex, sexual 
orientation, national origin, age, marital status, 
pregnancy, disability, disabled veterans or Viet¬ 


nam Era veteran’s status, or any other classifica¬ 
tion that precludes a person from consideration 
as an individual. Send applications to Dr. Martin 
S. Roden, Chair, Electrical and Computer Engi¬ 
neering, California State University, Los Ange¬ 
les, CA 90032. Telephone (213) 224-3552 for addi¬ 
tional information. 


THE PENNSYLVANIA STATE UNIVERSITY 
Computer Engineering 

Applications are invited for tenure-track and 
visiting faculty positions at all levels. Can¬ 
didates from all areas of computer engineering 
(hardware and software) will be considered. The 
computer engineering program at the Pennsyl¬ 
vania State University is within the Department 
of Electrical Engineering which has over 50 
faculty members, and approximately 1500 under¬ 
graduate majors, 170 graduate students. Can¬ 
didates should have a PhD in Electrical/Com¬ 
puter Engineering or related areas. There are 15 
faculty members within the computer engineer¬ 
ing program. Excellent instruction and research 
computing facilities are available within the 
department, college and at the university com¬ 
puting center. 

Please send your letter of application, resume, or 
inquiries, together with three references to: T. 
Feng, Computer Engineering Program, Depart¬ 
ment of Electrical Engineering, 129 Electrical 
Engineering East, Box C, The Pennsylvania State 
University, University Park, PA 16802. 

Deadline for applications is March 31,1987 or un¬ 
til suitable qualified candidates are selected. An 
Equal Opportunity/Affirmative Action Employer. 


VISITING PROFESSORSHIPS 
& VISITING RESEARCH 
PROFESSORSHIPS 

School of Engineering and Applied Science 
The George Washington University 

Visiting Professorships at junior and senior 
levels are available in specialty areas that in¬ 
clude, but are not limited to, the following: 

• Application Areas of Management 

• Artificial Intelligence 

• Communications 

• Computer Aided Design 

• Computer Aided Manufacturing 

• Computer Assisted Engineering 

• Computer-Integrated Manufacturing 

• Computer Science 

• Environmental Engineering 

• Human Factors 

• Information Management 

• Management of Research and Develop- 

• Mathematical Optimization 

• Mechanical Engineering 

• Reliability 

• Robotics 

• Simulation 

• Stochastic Processes 

• Structural Engineering 

• Systems Analysis and Management 

• Water Resources 

Appointments are for one-year periods. Ap¬ 
plicants should send vita, including complete 
publication list, and three references to: 

Office of the Dean 

School of Engineering & Applied Science 
THE GEORGE WASHINGTON UNIVERSITY 
Washington, DC 20052 

The University is an affirmative action and equal 
opportunity employer. 
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Sperry has just made the supercom¬ 
puter super useful. By creating the 
logical extension to our micro-to-main- 
frame line...the Sperry Integrated 
Scientific Processor. 

Is it fast? 133 Million floating point 
operations per second. 

Will it handle high speed vector and 
scalar computations? Of course. 

Is it exotic? Not in the least. 

And that is truly revolutionary. 

For the first time, the “super” part 
and the computer part are completely 
integrated to function as one single 
system. With significant advantages 
over the host/peripheral arrangement 
the rest of the industry uses. 

Software support, for example, is 
available for the Sperry supercom¬ 
puter to an unprecedented degree. 
Including program development aids 
like interactive screen editing, 
debugging aids, and database manage¬ 


ment systems. So your people can get 
their applications up and running 
faster than ever possible before. 

Total integration also means the 
Scientific Processor doesn’t waste time 
reporting to a “host”. No running com¬ 
mentary on what it is doing. No 
shunting program and data files back 
and forth. No system software tasks, 
in fact. 

But there are times when a good 
supercomputer has to communicate. 
So Sperry has balanced computing 
speed with data access speed. The ISP 
does some very fast talking. 133 million 
words per second, and before you can 
say “data transfer”, it’s back at work. 

It will handle the most complex 
problems of engineering and science. 
Physical systems simulation. Struc¬ 
tural analysis. Seismic processing. 
Among others. 

And, if like any good tool, it has 


applications above and beyond those 
for which it was originally purchased, 
not to worry. There s an entry level 
system, with an uninterrupted growth 
path for expanding either the general 
purpose or supercomputer processor. 
Or both. 

In the mysterious and rather inbred 
field of supercomputers it took Sperry 
to create better tools for the businesses 
of science. 

For further information, or to 
arrange for a private consultation, 
call 1-800-547-8362, ext. 34. Or write, 
Sperry Corporation, P.O. Box 500, 

Blue Bell, PA 19424-0024. 

©Sperry Corporation 1985 

























Gould solutions adapt to your needs. 


Gould has the flexibility to adapt to your 
situation with the skill of a chameleon. 

Gould’s 32-bit CONCEPT/32®series 
provides a lot more computer for the 
price. Using Gould’s real-time 
operating system, MPX-32®, the 
CONCEPT/32 product line gives 
you the performance needed to han¬ 
dle your particular requirements. 

The PowerNode®series gives you 
the flexibility and versatility of UNIX®: 
Gould’s UTX/32 operating system is 
a unique combination of Berkeley 
BSD 4.2 with AT&T System V. 


Our “Compatibility Suite”of appli¬ 
cation software packages are 
operational across the entire Gould 

High Performance Solutions in Factory Automation, Computers, 
Instrumentation, Defense, and Semiconductors. 


PowerNode series.. .the widest 
range of Unix-based systems in 
the world. 

To succeed, Gould has evolved to 
meet the needs of our customers. 
Year after year. Gould continues 
to innovate with products like 
Hypersearch — a superior text 
retrieval system, and our 
unmatched, complete computer- 
based training package. 

For more information on how we can 
adapt to your needs, contact 
Gould Inc., Information Systems 
Computer Systems Division, 

6901 West Sunrise Boulevard, 

Fort Lauderdale, Florida 33313 
1-800-327-9716. 


■> GOULD 


Electronics 


CONCEPT/ 32, MPX-32. PowerNode and UTX/32 are 
registered trademarks ot Gould Inc. 

UNIX is a registered trademark of AT&T Bell Labs 











